Stack-allocated arrays

[Denis Koroskin]

On Wed, 12 Nov 2008 21:59:16 +0300, Sean Kelly <sean at invisibleduck.org>  
wrote:

> Andrei Alexandrescu wrote:
>> 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.
>
> It's an implementation detail, but when the owner thread dies it should  
> null the links for all the list nodes, assuming the data contained in  
> those nodes can be shared across threads.
>
>> 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?
>
> I suppose I'm wondering what the advantage is of this approach over  
> simply using dynamic memory.  Is it the fact that allocations are  
> non-locking?  Pure stack allocations make sense because all such  
> allocations are scoped and guaranteed to be extremely fast.

Not only it is almost as fast as stack allocation, it is much safer (you  
never get stack overflow, for example).

> So I suppose this is simply a parallel local "stack" for the same  
> purpose and the goal is to avoid the assembly magic necessary for an  
> alloca() type solution?  And if this is the case, then I assume that  
> sharing would be illegal (at least on D2)?
>
> My initial reaction is that I'm skeptical of any attempt at manual  
> replacement of built-in functionality.  It's been shown, for example,  
> that custom allocators often perform worse than the default allocators.
>   That aside, the general approach does seem reasonable.  Though I'd  
> still prefer we just get real stack-based dynamic allocation in D.  It  
> seems quite natural that "scope" should provide this for arrays as a QOI  
> feature, as it does for classes.
>

I agree, making "scope T[] t = new T[100];" stack-allocated is great.

// D1/D2
scope T[] t1 = new T[size]; // stack-allocated

// D2
shared scope T[] t2 = new T[size]; // Does it make any sense? Should it be  
an error?