www.digitalmars.com         C & C++   DMDScript  

D - I'm wondering about dynamic arrays

reply 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?
Apr 04 2004
parent reply 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.
Apr 04 2004
parent reply "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.
Apr 07 2004
parent reply 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?
Apr 08 2004
parent 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
Apr 09 2004