View mode: basic / threaded / horizontal-split · Log in · Help
September 18, 2012
Re: built-in array ptrEnd
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])
September 18, 2012
Re: built-in array ptrEnd
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 :)
September 18, 2012
Re: built-in array ptrEnd
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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home