When you set the length of a dynamic array, is it truly increases/decreases the size of the array, or is it creating a new array, then it copies the values of the old array into the new array, and then it deletes the old array, all behind the scenes?

In article <opr5xy50de1s9n15@saturn>, SpookyET says...
>
>When you set the length of a dynamic array, is it truly increases/decreases the size of the array, or is it creating a new array, then it copies the values of the old array into the new array, and then it deletes the old array, all behind the scenes?

It does what it needs to do and you can't control it.  It may do either,
depending on whether it can give as much more space as you want in place.
It seems that somewhat more than you ask for is given initially, and when it
needs to realloc space it does so, moves it, and there is some unspecified
amount of reserve space, currently somewhere between 30 and 100 percent more
made available in place.  Small increments usually do not cause a move (a binary
copy of the old), larger ones will.  If the size is cut back, no move is
normally done (no promises).  If you cut it to zero length you will probably
realloc in a new place when you size it back upwards.  All of this is not a
compiler requirement, and may change with either a new compiler or a new garbage
collector.

"larry cowan" <larry_member@pathlink.com> wrote in message news:c4pn0m$p5m$1@digitaldaemon.com...
> In article <opr5xy50de1s9n15@saturn>, SpookyET says...
> >
> >When you set the length of a dynamic array, is it truly increases/decreases the size of the array, or is it creating a new array, then it copies the values of the old array into the new array, and then
it
> >deletes the old array, all behind the scenes?
>
> It does what it needs to do and you can't control it.  It may do either, depending on whether it can give as much more space as you want in place. It seems that somewhat more than you ask for is given initially, and when
it
> needs to realloc space it does so, moves it, and there is some unspecified amount of reserve space, currently somewhere between 30 and 100 percent
more
> made available in place.  Small increments usually do not cause a move (a
binary
> copy of the old), larger ones will.  If the size is cut back, no move is
> normally done (no promises).  If you cut it to zero length you will
probably
> realloc in a new place when you size it back upwards.  All of this is not
a
> compiler requirement, and may change with either a new compiler or a new
garbage
> collector.

I'd like to add that if it does reallocate the array, it does NOT delete the old one. The old one will eventually be reclaimed by the garbage collector if there are no other referrals to it.

In article <c51f3p$lv4$1@digitaldaemon.com>, Walter says...
>
>
>"larry cowan" <larry_member@pathlink.com> wrote in message news:c4pn0m$p5m$1@digitaldaemon.com...
>> In article <opr5xy50de1s9n15@saturn>, SpookyET says...
>> >
>> >When you set the length of a dynamic array, is it truly increases/decreases the size of the array, or is it creating a new array, then it copies the values of the old array into the new array, and then
>it
>> >deletes the old array, all behind the scenes?
>>
>> It does what it needs to do and you can't control it.  It may do either, depending on whether it can give as much more space as you want in place. It seems that somewhat more than you ask for is given initially, and when
>it
>> needs to realloc space it does so, moves it, and there is some unspecified amount of reserve space, currently somewhere between 30 and 100 percent
>more
>> made available in place.  Small increments usually do not cause a move (a
>binary
>> copy of the old), larger ones will.  If the size is cut back, no move is
>> normally done (no promises).  If you cut it to zero length you will
>probably
>> realloc in a new place when you size it back upwards.  All of this is not
>a
>> compiler requirement, and may change with either a new compiler or a new
>garbage
>> collector.
>
>I'd like to add that if it does reallocate the array, it does NOT delete the old one. The old one will eventually be reclaimed by the garbage collector if there are no other referrals to it.
>
Walter - does this mean that other pointers specifically will point to the old array unless updated?  I assume you are saying yes.  For example, if I am in a loop using pointers and add on to the end of the array with the basic reference, now my moving pointers are stuck in the old one.

But if in my loop I am using array[index] form, they will switch to the new one?

If not, is it possible to change an array safely which you are processing through element by element?  How?

Are there other types of references which are susceptible to this problem?  Is only the current array reference changed?

How can I make sure I am safe in the event of a reallocation - any guidlines?

larry cowan schrieb:

> Walter - does this mean that other pointers specifically will point to the old
> array unless updated?  I assume you are saying yes.  For example, if I am in a
> loop using pointers and add on to the end of the array with the basic reference,
> now my moving pointers are stuck in the old one.

Yes.

> But if in my loop I am using array[index] form, they will switch to the new one?

If you have done array ~= element, you have a new array assigned back to the variable array.

> If not, is it possible to change an array safely which you are processing
> through element by element?  How?  

Unless you are resizing the array, you can be sure that it's the *same* array you're working with. Soit goes back to what Walter said in the beginning - it is best to size arrays beforehand.

I would think that a wrapper class template for efficiently sizing arrays which don't create garbage is sometimes appropriate, but native D arrays make a wonderful bases for interface.

> Are there other types of references which are susceptible to this problem?  Is
> only the current array reference changed?

Only the array variable which gets assigned to gets updated. ~= is such an assignement. array.length = something also is.

> How can I make sure I am safe in the event of a reallocation - any guidlines?

Keep in memory that an array variable is a structure of a pointer to the 1st referenced element and length.

Among others, take care of the interface. Express what you mean - if you want changes to be reliably passed back to the caller of the function, use inout. It is good for the reader evemn if you don't resize the array and thus the changes propagate anyway.

-eye