Pointers and Arrays in C-Style Code

When a programmer first meets array alongside vector, a natural question follows. If vector is so much more flexible, why would anyone bother with an array at all? And when the language already provides built-in arrays, why add another option? These questions are reasonable, and the answers reveal a set of trade-offs rather than a single winner. This article starts from the beliefs that tend to mislead people here, then works through what is actually true.

Notice what the question actually asks. Why use an array when vector is more flexible? The answer given is that an array is less flexible, and that is exactly its purpose. It is simpler. Simplicity is not just a matter of tidiness. It changes how the elements are reached in memory, and that change can matter for speed.

Consider the choice in plain terms. A vector keeps its elements on the free store, which is the memory pool used for dynamic allocation. The program reaches those elements indirectly, through the vector acting as a handle. An array can instead place its elements directly on the stack. Each approach asks the program to do a different amount of work before it can read a value.

The diagram shows the two paths. Reading an array element that lives directly on the stack needs no intermediate hop. Reading a vector element goes through the handle first. That saved hop is where the performance advantage of a simpler container comes from. The source also warns that the stack is a limited resource, so the speed of an array has to be weighed against the risk of stack overflow. Placing elements on the stack is not free; it spends a finite resource.

Subscripting is how a program asks for one element by position. Written as arr[i], it behaves as if the program dereferenced arr plus i, meaning it starts at the location of the first element and moves forward by i element-sized steps. The step size is the size of the type the pointer refers to. That is why the type of a pointer matters: it decides how far each step travels.

The diagram captures the idea. Each index moves the reading position forward by whole element-sized steps from the start. As long as the pointer's type matches the real elements, every step lands exactly on the start of the next element. The arithmetic depends entirely on that match.

In this expression, i is the index and s is the size, in bytes, of the type the pointer refers to. The offset is how far from the first element the read lands. If s matches the size of the real elements, the offset is always a whole number of elements. If s is smaller, the offset can fall partway through an element.

A built-in array does not carry its size along with it the way an array object does. The information about how many elements exist must be tracked separately, which is a common source of errors. The more serious issue is decay. Decay is the conversion in which a built-in array's name is treated as a pointer to its first element. For most purposes this conversion is harmless, and it is how built-in arrays are passed around in older C-style code. Once decay happens, the size the program relied on is no longer attached to the value it is working with.

The second comparison is between array and the built-in array the language provides directly. The source gives three reasons an array is preferred. First, an array knows its size, which makes it straightforward to use with standard-library algorithms that need to know where a sequence ends. Second, an array can be copied using assignment or initialization. Third, and the source calls this its main reason, an array saves the programmer from surprising and nasty conversions to pointers.

The three columns show the trade-off rather than a winner. A vector gives flexibility and pays for it with an indirect path to its elements. An array gives up flexibility to keep the sequence simple and direct. A built-in array sits closest to the language and carries the most risk of losing its size at decay. The source's advice follows from this: when a fixed-size sequence is needed and the sequence should keep its identity, array is the safer choice over a built-in array that will be passed around as a pointer.

An array is less flexible than a vector because it is simpler, and that simplicity can yield a real performance advantage. Its elements can sit directly on the stack, so reading them avoids the handle-based step a vector requires, though the stack is a limited resource. A built-in array loses its size information when it decays to a pointer, and subscripting through a pointer of a mismatched type can compute an offset that lands inside the wrong element. Among the choices, array is preferred over a built-in array for its size awareness, copyability, and freedom from unsafe pointer conversions, while vector remains the choice when flexibility matters most.