Stack-allocated arrays

[Dave]

"Dave" <Dave_Member at pathlink.com> wrote in message 
news:gffgig$1ge6$1 at digitalmars.com...
> "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
> news:gff7g0$t54$1 at digitalmars.com...
>> KennyTM~ wrote:
>>> The best solution I can think of, without compiler modification is a 
>>> struct/class that contains a static array member T[1024] and a dynamic 
>>> array member T[] initialized to null; and the code chooses which member 
>>> to use in the constructor. But this always occupies 1024*T.sizeof bytes 
>>> and there will always be a conditional (if) sticked to all access 
>>> methods.
>>
>> This entire discussion gets me thinking - could an alternate stack be a 
>> good (or even better) solution? Consider a global per-thread 
>> "superstack" - a growable region that allocates memory in large chunks 
>> and makes sub-chunks accessible in a strictly LIFO manner. The primitives 
>> of the superstack are as follows:
>>
>> void* SuperStack.allocate(size_t bytes);
>> void SuperStack.free(size_t bytes);
>> size_t SuperStack.slack();
>>
>> The SuperStack's management is a singly-linked list of large blocks. The 
>> slack function returns how many bytes are left over in the current chunk. 
>> If you request more than slack bytes, a new chunk is allocated etc. A 
>> SuperStack can grow indefinitely (and is susceptible to leaks).
>>
>> Some convenience functions complete the picture:
>>
>> T[] SuperStack.array(T)(size_t objects);
>> enum Uninitialized { yeahIKnow }
>> T[] SuperStack.array(T)(size_t objects, Uninitialized);
>>
>> Freeing chunks should not be done immediately in order to avoid 
>> pathological behavior when a function repeatedly allocates and frees a 
>> chunk just to fulfill some small data needs.
>>
>> With the SuperStack in place, code could look like this:
>>
>> void foo(in size_t s)
>> {
>>     auto a = SuperStack.array(int)(s, Uninitialized.yeahIKnow);
>>     scope(exit) SuperStack.free(s);
>>     ... play with a ...
>> }
>>
>> Is there interest for such a thing?
>>
>
> That would be interesting and even better if it could be a built-in (not
> clear on if that was the intention or not).
>
> The reason for having it be a built-in is (IMO) it's important for D to
> provide language constructs that can improve performance for common things
> like allocating temporary, scope-limited arrays and classes, especially 
> with
> the new direction D2 discussions have been heading in lately (like pure
> functions and such).
>

Oh, and any built-in syntax needs to provide a way to allocate uninitialized 
data also (yeah, I know)...

>>
>> Andrei
>
>