What's the point of static arrays ?

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Jul 9 16:21:41 UTC 2020


On Thu, Jul 09, 2020 at 12:12:06PM +0000, wjoe via Digitalmars-d-learn wrote:
> + The size is known at compile time.
> 
> vs.
> 
> - Can neither grow nor shrink them
> - Can't append elements
> - Can't remove elements

Consider a 3D game in which you represent vectors as static arrays of 4
elements (homogenous representation).  In this case, it's a plus to not
be able to append/remove elements, because the rest of the code expects
vectors that are exactly 4 elements long.


> - Can't slice them
> - Can't range them

Sure you can.


> - Assignment copies the whole array, as in int[5] a; auto b = a;

Sometimes this is desirable.  Consider the 3D game example.  Suppose
you're given a vector and need to perform some computation on it. If it
were a dynamic array, you'd need to allocate a new array on the heap in
order to work on it without changing the original vector. With a static
array, it's passed by value to your function, so you just do what you
need to do with it, and when you're done, either discard it (== no work
because it's allocated on the stack) or return it (== return on the
stack, no allocations).


> - Size is limited by stack
> - Stack overflow issues

You *can* allocate static arrays on the heap, in which case they become
closer to dynamic arrays.  Generally, the cases for which static arrays
are useful are when the size isn't huge; for huge arrays it makes more
sense to just use dynamic arrays.

You can also have classes that contain large static arrays: in this
case, the usefulness comes from having the array embedded in the class
object itself, rather than being a separate heap allocation + another
level of indirection.


[...]
> Considering the many downsides why would I ever want to choose a
> static over a dynamic array ?

It depends on your needs.  If you know you're always going to be trading
in vectors of a fixed size, like 4-element vectors in aforementioned 3D
game, then there's no need to put extra GC (or whatever allocator)
pressure on your code, just trade in T[4].  You also skip bounds checks
in many cases, since the length is known at compile-time.  You get
by-value semantics, which is generally much easier to reason about than
by-reference semantics.  You avoid an extra level of indirection, which
can matter in hotspots.

If your arrays are going to change in length, then static arrays aren't
what you need; just use dynamic arrays. They serve different purposes.


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.


More information about the Digitalmars-d-learn mailing list