Built-in Arrays and Pointer Decay

Once you know vector, a natural question follows: if vector is more flexible, why would anyone choose array? The answer is not that array is more powerful. Array gives up flexibility in exchange for simplicity, and in some situations that trade is worth making. As you read, keep one question in mind: what does the program know about the container, and what can the program do with it? The answers differ between vector, array, and a built-in array, and most of the practical differences follow from those answers.

The source names two practical advantages an array has over a built-in array. The first is that an array knows its size. The second is that an array can be copied using the assignment operator or through initialization, so it behaves like an ordinary value that can be passed around and duplicated. A built-in array does not support copying in that same way, and it does not carry its length. The table below lines up the three containers on the questions that matter most in practice.

Array is less flexible than vector, and because of that it is simpler. A fixed-size container does not need to manage growth, so it has fewer moving parts to reason about. There is no need to think about reallocating storage when more elements arrive, because the number of elements never changes.

Performance is the other side of the same trade. A vector acts as a handle to elements that are allocated on the free store. Reaching an element through a handle involves an extra step, and allocating and later deallocating those elements has its own cost. An array whose elements sit directly on the stack avoids both costs. The source is careful about this claim: the advantage is real in some programs and is not guaranteed in all of them.

Storing elements on the stack is not free. The stack is a limited resource, and this limitation is especially pronounced on some embedded systems. Because of that, stack overflow is a serious risk, which the source describes as nasty. A large array placed on the stack consumes stack space that the rest of the program also needs. The performance benefit of stack allocation therefore has to be weighed against the size of the data.

The practical rule that follows is that a small, fixed number of elements is a good fit for the stack. A very large collection is a poor fit, and a container that uses the free store may be the better choice for it. The diagram shows why size matters: the large frame claims a share of a limit that is shared by every call in the program.

A built-in array passed to a function generally decays into a pointer to its first element. The function then sees only that pointer, and the knowledge of the array's length and element type can be lost along the way. The source describes this as a set of nasty conversions to pointers. An array can also be explicitly passed to a C-style function that expects a pointer, so the conversion is sometimes deliberate and sometimes accidental.

The real danger appears when a pointer of one type is used to subscript an array of a different type. Think of a pointer to a base type that is used to step through an array of a derived type. Subscripting moves the pointer by the size of the type it points to. If that stepping size does not match the size of the elements actually stored, the computed address points to the wrong place.

The source assumes that sizeof(Shape) is less than sizeof(Circle). Under that assumption, stepping a Shape pointer by one position across a Circle array does not reach the next Circle. It lands partway into the element that came before. Subscripting a Circle array through a Shape pointer therefore gives a wrong offset, and reading or writing through it touches the wrong data. The numbers used below, 8 and 16 bytes, are only illustrative. The source does not give specific sizes; what matters is the inequality and the mismatch it creates.