On Tue, 18 Sep 2012 17:04:53 -0400, Ben Davis <[email protected]> wrote:
On 18/09/2012 21:10, Nick Sabalausky wrote:
On Tue, 18 Sep 2012 15:43:37 +0200
"monarch_dodra" <[email protected]> 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
