brad@domain.invalid wrote:
<snip>
> Sorry if I am being completely stupid here, but are you saying that dynamic arrays in D have an underlying length that is not equal to their actual length?  And that this underlying allocated size increases with powers of two? 

In my experiments a while back, I found that it increases by powers of 2 up to 2 KB, and then by multiples of 2 KB.

> If so, I think that there is a serious lack of documentation about a fundamental D data structure.  The online docs specifically mention that increasing the size of an array by one at a time will be expensive - in my mind this implies that the .length is the actual size. 

It's not as expensive as that.  But an array can still be reallocated more than once if .length is repeatedly increased.

For example, this

    int[] qwert;
    for (int i = 0; i < 256; i++) {
        qwert ~= i*i;
    }

would cause up to nine allocations, of sizes 1, 2, 4, 8, 16, 32, 64, 128 and then 256.  Whereas if the length had been set to 256 in the first place, it would only need to allocate once.

However, I don't see how the "more practical approach" given here

http://www.digitalmars.com/d/arrays.html#resize

is better than

    int[] array = new int[100];
    array.length = 0;
    int c;
    while ((c = getinput()) != 0) {
        array ~= c;
    }

nor why not improve matters by selecting an initial guess that's a power of 2.

> If there is an underlying allocation size, it should be exposed as a properly and be allowed to be changed.

It seems that the underlying allocation size is a property of the heap-allocated block of memory, rather than of the array itself.  But yes, it could be exposed as a property of the array - it would look up the array's starting address in the heap allocation table (or whatever it is) to find the length, in the same way the length setter does.  As for setting the allocation size, I guess it would force a reallocation?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
<snip>
> It seems that the underlying allocation size is a property of the heap-allocated block of memory, rather than of the array itself.  But yes, it could be exposed as a property of the array - it would look up the array's starting address in the heap allocation table (or whatever it is) to find the length, in the same way the length setter does.  As for setting the allocation size, I guess it would force a reallocation?

And for what isn't at the beginning of a heap block (slices not beginning at 0, static arrays viewed as dynamic, array views of static/stack data, stuff allocated by malloc or an external API) I guess that the allocation size would be reported as zero, representing that any increase of length will cause reallocation.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsnen9alz23k2f5@nrage.netwin.co.nz...
> So, no guarantess then. The current GC only does a pass when you allocate memory, so presuming you don't allocate it during the concatenation, it should be safe, right?

Yes.