www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is it bad practice to alter dynamic arrays that have references to

reply simendsjo <simen.endsjo pandavre.com> writes:
Just tell me if this is frowned upon... The reason I posted on SO is 
because I think it can help making people aware of D.

http://stackoverflow.com/questions/3416657/is-it-bad-practice-to-alter-dynamic-arrays-that-have-references-to-them

Let me know if it's not accepted to crosspost like this.
Aug 05 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 05 Aug 2010 13:10:44 -0400, simendsjo <simen.endsjo pandavre.com>  
wrote:

 Just tell me if this is frowned upon... The reason I posted on SO is  
 because I think it can help making people aware of D.

 http://stackoverflow.com/questions/3416657/is-it-bad-practice-to-alter-dynamic-arrays-that-have-references-to-them
That is a very good overview of how arrays work, one thing you are missing is this: auto a = [1,2,3]; a.length = 4; Due to the implementation of the runtime, the a.length = x line reallocates the array. This is because the minimum size of an array is 15 bytes (16 bytes + 1 byte to store the "used" length). So the first line allocates an integer array in a 15-byte block, but appending one more 4-byte integer makes it grow to a 31-byte block, which means a realloc. Note that this is implementation-defined behavior, so you should not rely on this. Your confusion comes from expecting that the cause of a moving is because of the slice or because of b. In answer to your question, it is fine to keep multiple references to arrays, to slice arrays and keep multiple slices to the array, and to modify the array through those references or slices. There is a lot of code which depends on these properties to write extremely high-performing code. I would say you will run into somewhat puzzling behavior if you are appending to an array *and* changing the original data and expect to have all the references update automatically. While it's not illegal or even bad to do so (the runtime ensures no stomping, and ensures that all references remain valid), your program logic may fail because the decision to reallocate is implementation-defined. One helpful function to note is the capacity function: http://digitalmars.com/d/2.0/phobos/object.html#capacity This gives you the capacity of the array, or the largest length it can be set to without reallocating. If it's 0, that means any append will reallocate. This can allow deterministic behavior when appending. Or you can just dup the array if you want to ensure you don't mess up the original copy.
 Let me know if it's not accepted to crosspost like this.
I think there is no problem with that. -Steve
Aug 05 2010
parent reply simendsjo <simen.endsjo pandavre.com> writes:
On 05.08.2010 19:35, Steven Schveighoffer wrote:
 On Thu, 05 Aug 2010 13:10:44 -0400, simendsjo
 <simen.endsjo pandavre.com> wrote:
(...)
 One helpful function to note is the capacity function:

 http://digitalmars.com/d/2.0/phobos/object.html#capacity

 This gives you the capacity of the array, or the largest length it can
 be set to without reallocating. If it's 0, that means any append will
 reallocate. This can allow deterministic behavior when appending. Or you
 can just dup the array if you want to ensure you don't mess up the
 original copy.
Ah, that's really good to know! So I can see if it will reallocate using bool willReallocate = array.capacity < (array.length + numberOfItemsToAppend) ?
 Let me know if it's not accepted to crosspost like this.
I think there is no problem with that.
Good, then I'll keep on doing that then. Thanks a lot for your answer!
 -Steve
Aug 05 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 05 Aug 2010 14:41:12 -0400, simendsjo <simen.endsjo pandavre.com>  
wrote:

 On 05.08.2010 19:35, Steven Schveighoffer wrote:
 On Thu, 05 Aug 2010 13:10:44 -0400, simendsjo
 <simen.endsjo pandavre.com> wrote:
(...)
 One helpful function to note is the capacity function:

 http://digitalmars.com/d/2.0/phobos/object.html#capacity

 This gives you the capacity of the array, or the largest length it can
 be set to without reallocating. If it's 0, that means any append will
 reallocate. This can allow deterministic behavior when appending. Or you
 can just dup the array if you want to ensure you don't mess up the
 original copy.
Ah, that's really good to know! So I can see if it will reallocate using bool willReallocate = array.capacity < (array.length + numberOfItemsToAppend) ?
Yes, except the condition should be <=. And that function is implementation independent (the value returned isn't, but it's guaranteed that willReallocate should reflect whether the runtime will reallocate)
 Let me know if it's not accepted to crosspost like this.
I think there is no problem with that.
Good, then I'll keep on doing that then. Thanks a lot for your answer!
No problem! -Steve
Aug 05 2010
parent reply simendsjo <simen.endsjo pandavre.com> writes:
On 05.08.2010 20:50, Steven Schveighoffer wrote:
 On Thu, 05 Aug 2010 14:41:12 -0400, simendsjo
 <simen.endsjo pandavre.com> wrote:

 On 05.08.2010 19:35, Steven Schveighoffer wrote:
 On Thu, 05 Aug 2010 13:10:44 -0400, simendsjo
 <simen.endsjo pandavre.com> wrote:
(...)

(...)
 Ah, that's really good to know! So I can see if it will reallocate using
 bool willReallocate = array.capacity < (array.length +
 numberOfItemsToAppend)
 ?
Yes, except the condition should be <=. And that function is implementation independent (the value returned isn't, but it's guaranteed that willReallocate should reflect whether the runtime will reallocate)
bool willReallocate(T)(T[] array, T[] toAppend) { return array.capacity < (array.length + toAppend.length); } int[] a = [0]; auto aOldPtr = a.ptr; assert(a.capacity == 3); // a.length == a.capacity, so no reallocation int[] b = [1,2]; assert(!willReallocate(a, b)); a ~= b; assert(a.ptr == aOldPtr); // c.length == 0, so still no int[] c; assert(!willReallocate(a, c)); a ~= c; assert(a.ptr == aOldPtr); // there, a.length > a.capacity and reallocation int[] d = [3]; assert(willReallocate(a, d)); a ~= d; assert(a.ptr != aOldPtr);
Aug 05 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 05 Aug 2010 15:23:13 -0400, simendsjo <simen.endsjo pandavre.com>  
wrote:

 On 05.08.2010 20:50, Steven Schveighoffer wrote:
 On Thu, 05 Aug 2010 14:41:12 -0400, simendsjo
 <simen.endsjo pandavre.com> wrote:

 On 05.08.2010 19:35, Steven Schveighoffer wrote:
 On Thu, 05 Aug 2010 13:10:44 -0400, simendsjo
 <simen.endsjo pandavre.com> wrote:
(...)

(...)
 Ah, that's really good to know! So I can see if it will reallocate  
 using
 bool willReallocate = array.capacity < (array.length +
 numberOfItemsToAppend)
 ?
Yes, except the condition should be <=. And that function is implementation independent (the value returned isn't, but it's guaranteed that willReallocate should reflect whether the runtime will reallocate)
bool willReallocate(T)(T[] array, T[] toAppend) { return array.capacity < (array.length + toAppend.length); } int[] a = [0]; auto aOldPtr = a.ptr; assert(a.capacity == 3); // a.length == a.capacity, so no reallocation int[] b = [1,2]; assert(!willReallocate(a, b)); a ~= b; assert(a.ptr == aOldPtr); // c.length == 0, so still no int[] c; assert(!willReallocate(a, c)); a ~= c; assert(a.ptr == aOldPtr); // there, a.length > a.capacity and reallocation int[] d = [3]; assert(willReallocate(a, d)); a ~= d; assert(a.ptr != aOldPtr);
Oh right, for some reason, my brain did a fantastic translation of your statement to: bool willNOTReallocate = array.length + numberOfItemsToAppend < array.capacity; Which I then pointed out should really be <= Sorry :) -Steve
Aug 05 2010