On Tue, 18 Sep 2012 15:43:37 +0200
"monarch_dodra" <monarchdodra@gmail.com> wrote:

> On Tuesday, 18 September 2012 at 12:06:15 UTC, Steven Schveighoffer wrote:
> >
> > There is another reason to avoid this.
> >
> > Note that if I have two consecutive blocks of memory:
> >
> > 0...4
> > and
> > 4...8
> >
> > If we define an array that points to the first block as a pointer to 0 and a pointer to 4, then that array also effectively points at the second block (4...8).  The way the GC works, it will not release the second block as long as you have a pointer to the first, even though the second pointer is not technically pointing at the block.
> >
> > -Steve
> 
> That's a good point. I also shows another danger of ptrEnd: Not only is it not a reference to the current range, it could *also* be a reference to an un-related range.

FWIW, a ptrLast would avoid that (ie, arr.ptrLast == &arr[$-1])

On 18/09/2012 21:10, Nick Sabalausky wrote:
> On Tue, 18 Sep 2012 15:43:37 +0200
> "monarch_dodra" <monarchdodra@gmail.com> wrote:
>
>> On Tuesday, 18 September 2012 at 12:06:15 UTC, Steven
>> Schveighoffer wrote:
>>>
>>> There is another reason to avoid this.
>>>
>>> Note that if I have two consecutive blocks of memory:
>>>
>>> 0...4
>>> and
>>> 4...8
>>>
>>> If we define an array that points to the first block as a
>>> pointer to 0 and a pointer to 4, then that array also
>>> effectively points at the second block (4...8).  The way the GC
>>> works, it will not release the second block as long as you have
>>> a pointer to the first, even though the second pointer is not
>>> technically pointing at the block.
>>>
>>> -Steve
>>
>> That's a good point. I also shows another danger of ptrEnd: Not
>> only is it not a reference to the current range, it could *also*
>> be a reference to an un-related range.

Does the above not also mean that the second array's 'ptr' prevents the first array from being garbage-collected?

In any case, maybe the heap leaves gaps (perhaps if it has to insert metadata), so this is a non-issue anyway?

> FWIW, a ptrLast would avoid that (ie, arr.ptrLast == &arr[$-1])

That would make the problem worse for zero-length arrays though. Don't forget the corner-cases :)

On Tue, 18 Sep 2012 17:04:53 -0400, Ben Davis <entheh@cantab.net> wrote:

> On 18/09/2012 21:10, Nick Sabalausky wrote:
>> On Tue, 18 Sep 2012 15:43:37 +0200
>> "monarch_dodra" <monarchdodra@gmail.com> wrote:
>>
>>> That's a good point. I also shows another danger of ptrEnd: Not
>>> only is it not a reference to the current range, it could *also*
>>> be a reference to an un-related range.
>
> Does the above not also mean that the second array's 'ptr' prevents the first array from being garbage-collected?

No, a pointed-at location in memory does not refer to the prior bytes, only the subsequent bytes.

>
> In any case, maybe the heap leaves gaps (perhaps if it has to insert metadata), so this is a non-issue anyway?

Yes and no.  In the case of a block allocated as an array, metadata is stored, and the runtime takes care to put at least one byte between the allocated block and the next.  The main reason being, you can do arr[$..$], and even with a single-pointer array type, it points at the next block.

However, it's definitely possible to allocate (and have slices point at) blocks that do not have padding.

>> FWIW, a ptrLast would avoid that (ie, arr.ptrLast == &arr[$-1])
>
> That would make the problem worse for zero-length arrays though. Don't forget the corner-cases :)

Agreed, referencing one *past* the last element is a much more useful idiom, as I've experienced with C++ iterators and D ranges.

-Steve