What's the point of static arrays ?

[Simen Kjærås]

On Friday, 10 July 2020 at 10:13:23 UTC, wjoe wrote:
> However stack memory needs to be allocated at program start. I 
> don't see a huge benefit in allocation speed vs. heap 
> pre-allocation, or is there?
> I mean 1 allocation vs 2 isn't going to noticeably improve 
> overall performance.

You seem to still be thinking of static arrays as the same kind 
of "thing" as a dynamic array. They're (usually) more like ints 
or structs than containers: they're generally small, they're 
often parts of other structures or classes, and they're fairly 
often the element type of a larger dynamic array. For instance, a 
bitmap image could be a byte[4][][], with dynamic dimensions 
3840x2160. If instead of byte[4] we used byte[], not only would 
things grind to a halt immediately, we'd also be using massively 
more memory.

When you're using a static array on the stack, it's usually just 
because it's more convenient to say `int[16] buffer;` than `auto 
buffer = new int[16];`. The fact it may be faster is mostly a 
side benefit. Also, even if you did preallocate such a buffer, 
there's the overhead of remembering how to get to it, the work of 
setting it up, probably a function call on use, etc. The 
alternative is terser, built-in, more obvious to maintainers, 
pretty unlikely to overflow the stack, and very unlikely to be 
slower. Allocating a multi-MiB static array on the stack is a 
sign that you're using your screwdriver as a hammer, and there 
are probably better ways to do what you're trying to do.


>>     a[]
> What happens here exactly ?

It creates a dynamic array that points to the data in the static 
array. It's just shorthand for a[0..$]:

unittest {
     int[4] a = [1,2,3,4];

     auto b = a[];
     assert(b.length == 4);
     assert(b.ptr == &a[0]);

     auto c = a[0..$];
     assert(b is c);
}

--
   Simen