More discussions about variable-sized stack-allocated arrays in C++, it seems there is no yet a consensus:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf

I'd like variable-sized stack-allocated arrays in D.

Bye,
bearophile

On Sunday, 20 October 2013 at 14:25:37 UTC, bearophile wrote:
> I'd like variable-sized stack-allocated arrays in D.

I think I would too, though it'd be pretty important, at least for @safe, to get scope working right.

Ideally, the stack allocated array would be a different type than a normal array, but offer the slice operator, perhaps on alias this, to give back a normal T[] in a scope storage class (the return value could only be used in a context where references cannot escape).

This way, the owner is clear and you won't be accidentally storing it somewhere.



An alternative to a stack allocated array would be one made from a thread-local region allocator, which returns a Unique!T or similar, which frees it when it goes out of scope. Such an allocator would be substantially similar to the system stack, fast to allocate and free, although probably not done in registers and perhaps not as likely to be in cpu cache. But that might not matter much anyway, I don't actually know.

On 10/20/13 16:25, bearophile wrote:
> More discussions about variable-sized stack-allocated arrays in C++, it
> seems there is no yet a consensus:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf
>
> I'd like variable-sized stack-allocated arrays in D.
>
> Bye,
> bearophile

Good read, but many of the problems don't apply to D ;)

The problem is that it'll probably be like using alloca, which doesn't get cleaned up until after the function exits. Using it within a loop is bound to cause a stack overflow. I wonder if there's something we can do to 'fix' alloca in that respect.

L.

On 10/20/2013 7:25 AM, bearophile wrote:
> More discussions about variable-sized stack-allocated arrays in C++, it seems
> there is no yet a consensus:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf
>
> I'd like variable-sized stack-allocated arrays in D.

They're far more trouble than they're worth.

Just use:

    auto a = new T[n];

Stack allocated arrays are far more trouble than they're worth. But what about efficiency? Here's what I often do something along the lines of:

    T[10] tmp;
    T[] a;
    if (n <= 10)
	a = tmp[0..n];
    else
	a = new T[n];
    scope (exit) if (a != tmp) delete a;

The size of the static array is selected so the dynamic allocation is almost never necessary.

On 10/20/13 9:33 AM, Walter Bright wrote:
> Stack allocated arrays are far more trouble than they're worth. But what
> about efficiency? Here's what I often do something along the lines of:
>
>      T[10] tmp;
>      T[] a;
>      if (n <= 10)
>      a = tmp[0..n];
>      else
>      a = new T[n];
>      scope (exit) if (a != tmp) delete a;
>
> The size of the static array is selected so the dynamic allocation is
> almost never necessary.

Fallback allocators will make it easy to define an allocator on top of a fixed array, backed by another allocator when capacity is exceeded. BTW I'm scrambling to make std.allocator available for people to look at and experiment with.


Andrei

On Sunday, 20 October 2013 at 16:33:35 UTC, Walter Bright wrote:
> On 10/20/2013 7:25 AM, bearophile wrote:
>> More discussions about variable-sized stack-allocated arrays in C++, it seems
>> there is no yet a consensus:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf
>>
>> I'd like variable-sized stack-allocated arrays in D.
>
> They're far more trouble than they're worth.
>
> Just use:
>
>     auto a = new T[n];
>
> Stack allocated arrays are far more trouble than they're worth. But what about efficiency? Here's what I often do something along the lines of:
>
>     T[10] tmp;
>     T[] a;
>     if (n <= 10)
> 	a = tmp[0..n];
>     else
> 	a = new T[n];
>     scope (exit) if (a != tmp) delete a;
>
> The size of the static array is selected so the dynamic allocation is almost never necessary.

But delete is deprecated. ;)

On Sunday, 20 October 2013 at 16:33:35 UTC, Walter Bright wrote:
> Stack allocated arrays are far more trouble than they're worth. But what about efficiency? Here's what I often do something along the lines of:

Aye, that's a pretty good solution too.

>     scope (exit) if (a != tmp) delete a;

but I think you meant if(a is tmp) :)

Though, even that isn't necessarily right since you might use a to iterate through it (e.g. a = a[1 .. $]), so I'd use a separate flag variable for it.

On 10/20/2013 9:56 AM, Namespace wrote:
> But delete is deprecated. ;)

I know. But I wanted to show where to put the free, in the case where you're doing manual allocation.

Walter Bright:

> Just use:
>
>     auto a = new T[n];

Sometimes I don't want to do that.


> Stack allocated arrays are far more trouble than they're worth.

I don't believe that.


> But what about efficiency? Here's what I often do something along the lines of:
>
>     T[10] tmp;
>     T[] a;
>     if (n <= 10)
> 	a = tmp[0..n];
>     else
> 	a = new T[n];
>     scope (exit) if (a != tmp) delete a;
>
> The size of the static array is selected so the dynamic allocation is almost never necessary.

That's 7 lines of bug-prone code that uses a deprecated functionality and sometimes over-allocates on the stack. And I think you have to compare just the .ptr of those arrays at the end. And if you return one of such arrays you will produce nothing good. And what if you need 2D arrays? The code becomes even more complex. (You can of course create a matrix struct for that).

Dynamically sized stack allocated arrays are meant to solve all those problems: to offer a nice, compact, clean, easy to remember and safe syntax. To be usable for 2D arrays too; and when you pass or return one of them the data is copied by the compiler on the heap (sometimes this doesn't happen if the optimizing compiler allocates the array in the stack frame of the caller, as sometimes done for structs).

D dynamic array usage should decrease and D should encourage much more the usage of small stack-allocated arrays. This is what languages as Ada and Rust teach us. Heap allocation of arrays should be much less common, almost a special case.

----------------

Andrei Alexandrescu:

> Fallback allocators will make it easy to define an allocator on top of a
fixed array,

This over-allocates on the stack, and sometimes needlessly allocates on the heap or in an arena. Dynamic stack arrays avoid those downsides.

Bye,
bearophile

 One of my most anticipated C++14 features actually, hope they don't dawdle too much with the TS it apparently got pushed back into:(