• SpookyET (4/4) Apr 04 2004 When you set the length of a dynamic array, is it truly
• larry cowan (12/16) Apr 04 2004 It does what it needs to do and you can't control it. It may do either,
• Walter (12/29) Apr 07 2004 it
• larry cowan (11/41) Apr 08 2004 Walter - does this mean that other pointers specifically will point to t...
• Ilya Minkov (19/29) Apr 09 2004 If you have done array ~= element, you have a new array assigned back to...

SpookyET <not4_u hotmail.com> writes:

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?

larry cowan <larry_member pathlink.com> writes:

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.

"Walter" <walter digitalmars.com> writes:

"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.

larry cowan <larry_member pathlink.com> writes:

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?

Ilya Minkov <minkov cs.tum.edu> writes:

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