• Kevin Watters (5/5) Nov 24 2004 Just a quirk...
• Sean Kelly (4/13) Nov 24 2004 I think to make it less simple to produce bad code such as this:
• Ilya Minkov (9/12) Nov 25 2004 Because resizing an array is a very costy operation in D and you really
• Simon Buchan (16/27) Nov 27 2004 Well its the same for increment and all the assign operators as well,
• Ben Hinkle (5/10) Nov 28 2004 That would be nice. MinTL has a "reserve" template that reserves space f...

Kevin Watters <Kevin_member pathlink.com> writes:

Just a quirk...

Is there any reason you can do

array.length = array.length - 1;

..but not

array.length--; // ?

Sean Kelly <sean f4.ca> writes:

Kevin Watters wrote:
 Just a quirk...
 
 Is there any reason you can do
 
 array.length = array.length - 1;
 
 ..but not
 
 array.length--; // ?

I think to make it less simple to produce bad code such as this:

array[--length*2] = x;


Sean

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

Kevin Watters schrieb:
 Just a quirk...
 
 Is there any reason you can do

Because resizing an array is a very costy operation in D and you really 
don't want to do that for each element. Resizing is more costy than, 
say, in STL, because ownage and memory management are done differently 
from, say, STL. Keywords: Garbage Collection, Copy-on-Write convention.

As to reducing the array length... I'm not sure now, but i think it uses 
slice, not copy, so should incure almost no cost at all - as oppsed to 
increasing it. But i'm not sure it is worth an exception from the rules.

-eye

"Simon Buchan" <currently no.where> writes:

On Thu, 25 Nov 2004 17:00:57 +0100, Ilya Minkov <minkov cs.tum.edu> wrote:

 Kevin Watters schrieb:
 Just a quirk...
  Is there any reason you can do

 Because resizing an array is a very costy operation in D and you really  
 don't want to do that for each element. Resizing is more costy than,  
 say, in STL, because ownage and memory management are done differently  
 from, say, STL. Keywords: Garbage Collection, Copy-on-Write convention.

 As to reducing the array length... I'm not sure now, but i think it uses  
 slice, not copy, so should incure almost no cost at all - as oppsed to  
 increasing it. But i'm not sure it is worth an exception from the rules.

 -eye

Well its the same for increment and all the assign operators as well,
(*=, etc...) so its not an exception.

AFAIK, decreasing the length only tells the GC that it can use the memory
after the end now, increasing an array the first time moves it to GC
controlled mem (as opposed to the stack?) and afterwards only moves it if
increasing the length would hit already alloc'ed mem. (This is all
implentation dependant stuff, of course)

If so, its only _occasionally_ expensive... (But that is a big If)

Perhaps a .reserved array property? But that would be part of the GC, not  
the
array... I don't know the answer, but I do know that it should be a damn  
sight
easier to tell D you want to add one element.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Ben Hinkle" <ben.hinkle gmail.com> writes:

[snip]
 Perhaps a .reserved array property?

That would be nice. MinTL has a "reserve" template that reserves space for 
dynamic or associative arrays but it is limited to non-zero length arrays 
and it doesn't return the current amount of available space.

 But that would be part of the GC, not  the
 array... I don't know the answer, but I do know that it should be a damn 
 sight
 easier to tell D you want to add one element.

Usually one knows what element to add and so ~= is the way to go.