January 17, 2012
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
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
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
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
1 2
Next ›   Last »