On Mon, 15 May 2006 23:08:26 +1000, "Derek Parnell" <derek@psych.ward> wrote:

>void main()
>{
>    int[] a;
>    int[]* b;
>    int[]* c;
>
>    b = &a;
>    c = &a;
>    a.length= 40;
>    a[0] = 17;
>    writefln("%d %d", c.length, b.length);
>    writefln("%d %d", *c[0], *b[0]);
>}
>
>-------------------------
>This displays
>40 40
>17 17
>-------------------------
>
>But I still don't know why one would want to do this?

No, i certainly don't want to do this. I just expected from D's dynamic arrays what was described here in a more readable English as arrays being reference types. That's clearer now. Thanks

Max Samuha wrote:
> On Mon, 15 May 2006 23:08:26 +1000, "Derek Parnell" <derek@psych.ward>
> wrote:
> 
> 
>>void main()
>>{
>>   int[] a;
>>   int[]* b;
>>   int[]* c;
>>
>>   b = &a;
>>   c = &a;
>>   a.length= 40;
>>   a[0] = 17;
>>   writefln("%d %d", c.length, b.length);
>>   writefln("%d %d", *c[0], *b[0]);
>>}
>>
>>-------------------------
>>This displays
>>40 40
>>17 17
>>-------------------------
>>
>>But I still don't know why one would want to do this?
> 
> 
> No, i certainly don't want to do this. I just expected from D's
> dynamic arrays what was described here in a more readable English as
> arrays being reference types. That's clearer now. Thanks
> 

I have made some similar mistakes before, to be sure.  Essentially D's arrays are really structures, one of the fields of which being a pointer to the real data.  Sometimes this means another array variable will be pointing to the same data, but this leaves you when you try to muck with the array.

Although, in some (not all) cases you can get behavior like what you want by using inout parameters (or pointers), and in some other cases (still not all) you could probably use slice semantics.

-- Chris Nicholson-Sauls

There's one more question about arrays.

From D specs:

>A pointer to the start of a garbage collected object need not be maintained if a pointer to the interior of the object exists.
>char[] p = new char[10];
>char[] q = p[3..6];
>// q is enough to hold on to the object, don't need to keep
>// p as well.

If the garbage collector moves data referenced by p, i guess all pointers to slices of p will be updated correctly.

What if i set p to null or p goes out of scope and q is still reachable, will the memory (before q.ptr and after q.ptr + q.length - 1) that was pointed to by p be reclaimed by the garbage collector?

I should note, currently, DMD's implementation won't move anything you're pointing to.

And... as you probably know, memory is allocated in chunks from the operating system.  Without making a copy, you can't deallocate just one part.  So DMD won't currently.

However, if the memory were to be copied I'd expect it to be perfectly reasonable that the GC might not keep the old array data (although that would certainly be non-trivial for the GC to do.)

I wouldn't depend on it - and it seems brittle anyway, even if it were guaranteed.

-[Unknown]


> There's one more question about arrays.
> 
> From D specs:
> 
>> A pointer to the start of a garbage collected object need not be maintained if a pointer to the interior of the object exists.
>> char[] p = new char[10];
>> char[] q = p[3..6];
>> // q is enough to hold on to the object, don't need to keep
>> // p as well.
> 
> If the garbage collector moves data referenced by p, i guess all
> pointers to slices of p will be updated correctly.  
> 
> What if i set p to null or p goes out of scope and q is still
> reachable, will the memory (before q.ptr and after q.ptr + q.length -
> 1) that was pointed to by p be reclaimed by the garbage collector? 
> 

On Wed, 17 May 2006 22:07:12 -0700, Unknown W. Brackets wrote:

> I should note, currently, DMD's implementation won't move anything you're pointing to.

Even if the length is increased beyond the size that has been allocated for
a dynamic array? I thought that DMD allocated a new block of the right size
and copied data from the old block to it then released the old block back
to the GC.

I think that if the length is decreased then no copying goes on and that no
memory is released back to the GC, but can be later reused if the length
then is increased anywhere up to the original allocation size.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
18/05/2006 3:20:14 PM

Derek Parnell wrote:
> On Wed, 17 May 2006 22:07:12 -0700, Unknown W. Brackets wrote:
> 
>> I should note, currently, DMD's implementation won't move anything you're pointing to.
> 
> Even if the length is increased beyond the size that has been allocated for
> a dynamic array? I thought that DMD allocated a new block of the right size
> and copied data from the old block to it then released the old block back
> to the GC.
>  

Yes, that's what it does, but that resizing results from an explicit programmer action, and not from the GC. When W. Brackets mentioned "DMD's implementation" I believe he meant the GC only, which, as is known, indeed doesn't currently move anything.

> I think that if the length is decreased then no copying goes on and that no
> memory is released back to the GC, but can be later reused if the length
> then is increased anywhere up to the original allocation size.
> 


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Right, sorry if I was unclear.

When you resize an array, it makes a copy - it still doesn't move anything.  When I was talking about moving, I was meaning a compacting (defragmenting) garbage collector.

DMD's garbage collector holds onto any pointer references which are still active, even if you change the length of a dynamic array - so that issue shouldn't affect this.

For slices to work properly, the above must be guaranteed afaik.  But holding onto the memory around said slices need not be guaranteed.

PS: I've been called a lot of different things (Uncle Brackets, Big U, etc.), but I hadn't ever heard "W. Brackets".  Heh.

-[Unknown]


> Derek Parnell wrote:
>> On Wed, 17 May 2006 22:07:12 -0700, Unknown W. Brackets wrote:
>>
>>> I should note, currently, DMD's implementation won't move anything you're pointing to.
>>
>> Even if the length is increased beyond the size that has been allocated for
>> a dynamic array? I thought that DMD allocated a new block of the right size
>> and copied data from the old block to it then released the old block back
>> to the GC.
>>  
> 
> Yes, that's what it does, but that resizing results from an explicit programmer action, and not from the GC. When W. Brackets mentioned "DMD's implementation" I believe he meant the GC only, which, as is known, indeed doesn't currently move anything.