built-in array ptrEnd

Steven Schveighoffer schveiguy at yahoo.com
Tue Sep 18 15:12:00 PDT 2012


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

> On 18/09/2012 21:10, Nick Sabalausky wrote:
>> On Tue, 18 Sep 2012 15:43:37 +0200
>> "monarch_dodra" <monarchdodra at 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


More information about the Digitalmars-d mailing list