Walter Bright wrote:
> Greg Weber wrote:
>> I find myself wondering what actually happens when I create a dynamic array and concatenate items onto it.  I think I read in a post that memory will be over-allocated at times to avoid re-allocating.
>>
>> I think it would help out a lot to have an ability to specify
>> over-allocation.  Something like
>> uint a = [];
>> a.length = 3:10
>>
>> Where the array length is 3, but you are guaranteed to have memory allocation for 10, so you can be guaranteed that concatenation up to ten will not need to allocate memory.  This could help in the situation where there is concatenation in a loop, and the programmer over-sizes the array before the loop and re-sizes after the loop.
> 
> a.length = 10;
> a = a[0 .. 3];

I can sympathize with greg, I often use arrays as an intermediate memory allocator (when writing code that can't be garbage collected). But it would require dynamic arrays have a different shape; you would have to track the buffer size in addition to the number of elements... (or you check mallocs boundary tags if you want to be non-portable)

It would be nice to be able to set minimum allocation chunk size on a type-by-type basis; especially for small types. Or is that considered a compiler optimization?

Traveler Hauptman wrote:
> It would be nice to be able to set minimum allocation chunk size on a
> type-by-type basis; especially for small types. Or is that considered a
> compiler optimization?

D allows for custom memory allocation schemes by overloading operators new and delete for a class/struct, or by using malloc/free (or one's own allocator) directly.

Walter Bright wrote:
> Traveler Hauptman wrote:
>> It would be nice to be able to set minimum allocation chunk size on a type-by-type basis; especially for small types. Or is that considered a compiler optimization?
> 
> D allows for custom memory allocation schemes by overloading operators new and delete for a class/struct, or by using malloc/free (or one's own allocator) directly.

I was suggesting a compromise for array allocation between what D has now and what Greg was asking for. I'm assuming you can't overload new/delete for arrays and the fundamental types.

I gotta say though, when I first looked at D a couple years ago and saw that you gave access to the memory allocation layer with new/delete; I think I jumped up and did a little dance. (I write hard-realtime code)

Cheers

Greg Weber wrote:
>> AFAIK there's no way to shrink the memory allocated to an array, and the closest you can get is to call .dup on a slice. This will get you a copy of part of the array, allowing the original to be garbage collected (assuming no more references to it exist).
> 
> So here is my attempt.
> 
> bool downsize(T,I)(inout T[] arr, I downSize) {
>     static assert(is(I:size_t),"downsize needs an integer size parameter");
> 
>     if (downSize < arr.length) {
>         auto downsized = arr[0 .. downsize].dup;
>         arr = downsized;
>         return true;
>     }
>     return false;
> }
> 
> 
> bool allocate(T,I)(inout T[] arr, I reservedSize) {
>     static assert(is(I:size_t),"reserve needs an integer size parameter");
>     size_t l = arr.length;
>     if (reservedSize > l) {
>         arr.length = reservedSize;
>         arr.length = l;
>         return true;
>     }
>     return false;
> }
> 

Nice!

I hate to ccomplain however this is not the most efficient way to resize an array, unless the compiler is smart enough to remove the copy.

-Joel