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
