January 17, 2012 Re: Limitation with current regex API | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mail Mantis | Mail Mantis <mail.mantis.88@gmail.com> writes:
> 2012/1/17 Vladimir Panteleev <vladimir@thecybershadow.net>:
>> On Tuesday, 17 January 2012 at 01:44:37 UTC, Vladimir Panteleev wrote:
>>>
>>> On Monday, 16 January 2012 at 19:28:42 UTC, Jerry wrote:
>>>>
>>>> As far as I can tell, the only way to do this would be to capture every chunk of text, then iterate to determine the offsets.
>>>
>>>
>>> Not sure if this is what you were referring to, but you can do...
>>
>>
>> Even simpler: m.captures[1].ptr - s.ptr
>>
>> (s is the string being matched)
>
> Correct me if I'm wrong, but wouldn't this be better:
> (m_captures[1].ptr - s.ptr) / s[0].sizeof;
I *think* pointer arithmetic handles that. However this is much uglier than:
m_captures[1].begin
m_captures[1].end
Jerry
|
January 17, 2012 Re: Limitation with current regex API | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Tuesday, January 17, 2012 05:04:39 Timon Gehr wrote:
> I don't know exactly, since @safe is neither fully specified nor implemented. In my understanding, in @safe code, operations that may lead to memory corruption are forbidden. Pointer - pointer cannot, other kinds of pointer arithmetic may.
Pointer arithmetic is definitely forbidden in @safe, but I'm not sure that that forbids pointer - pointer, since it's not dangerous. It's changing a pointer via arithmetic which is dangerous.
- Jonathan M Davis
|
January 17, 2012 Re: Limitation with current regex API | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 17/01/12 10:40, Jonathan M Davis wrote:
> On Tuesday, January 17, 2012 05:04:39 Timon Gehr wrote:
>> I don't know exactly, since @safe is neither fully specified nor
>> implemented. In my understanding, in @safe code, operations that may
>> lead to memory corruption are forbidden. Pointer - pointer cannot, other
>> kinds of pointer arithmetic may.
>
> Pointer arithmetic is definitely forbidden in @safe, but I'm not sure that that
> forbids pointer - pointer, since it's not dangerous. It's changing a pointer
> via arithmetic which is dangerous.
>
> - Jonathan M Davis
My guess is that safe D is supposed to enforce C pointer semantics.
At least, code which is both @safe and pure must do so.
The semantics are currently enforced in CTFE.
pointer - pointer is undefined behaviour in C, if the pointers come from different arrays. It's OK if they are from the same array, which is true in this case.
|
January 17, 2012 Re: Limitation with current regex API | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | On 1/17/12 6:59 AM, Don Clugston wrote:
> On 17/01/12 10:40, Jonathan M Davis wrote:
>> On Tuesday, January 17, 2012 05:04:39 Timon Gehr wrote:
>>> I don't know exactly, since @safe is neither fully specified nor
>>> implemented. In my understanding, in @safe code, operations that may
>>> lead to memory corruption are forbidden. Pointer - pointer cannot, other
>>> kinds of pointer arithmetic may.
>>
>> Pointer arithmetic is definitely forbidden in @safe, but I'm not sure
>> that that
>> forbids pointer - pointer, since it's not dangerous. It's changing a
>> pointer
>> via arithmetic which is dangerous.
>>
>> - Jonathan M Davis
>
> My guess is that safe D is supposed to enforce C pointer semantics.
> At least, code which is both @safe and pure must do so.
> The semantics are currently enforced in CTFE.
>
> pointer - pointer is undefined behaviour in C, if the pointers come from
> different arrays. It's OK if they are from the same array, which is true
> in this case.
>
Yah, that C rule is to allow segmented memory architectures work properly. One possibility for D is to require a flat memory model, in which the difference between any two pointers can be taken.
Andrei
|
Copyright © 1999-2021 by the D Language Foundation