I’m currently in a C++ class, and today we covered arrays and <code>std::vector</code>.
On the surface, it feels obvious:
<code>std::vector</code> is safer, resizable, easier to manage, and part of the standard library. So here’s what genuinely confused me:
If vectors are better in almost every way…
why do raw arrays still exist?
From what I understand so far:
<ul>
<li>Raw arrays have fixed size.</li>
<li>They live on the stack (usually).</li>
<li>They don’t automatically know their own length.</li>
<li>They don’t resize.</li>
<li>They’re faster to allocate.</li>
</ul>
Vectors:
<ul>
<li>Allocate on the heap.</li>
<li>Resize dynamically.</li>
<li>Track their own size.</li>
<li>Provide bounds-checked access (<code>at()</code>).</li>
<li>Handle memory automatically.</li>
</ul>
As a student, the conclusion seems simple:
Use vectors. Avoid arrays.
But that feels too clean.
C++ isn’t designed to remove tools it’s designed to give you control. So I started thinking deeper about it.
Maybe raw arrays still matter because:
<ul>
<li>In embedded systems, memory layout and predictability matter.</li>
<li>In performance-critical code, avoiding heap allocation matters.</li>
<li>In legacy systems, arrays are everywhere.</li>
<li>In certain cases, stack allocation improves cache locality.</li>
</ul>
But then here’s the tension:
If safety prevents bugs, and bugs are expensive…
why would experienced developers willingly use something more error-prone?
Is the performance gain that significant?
Or is this more about understanding memory at a deeper level?
Another thing that stood out to me:
Vectors are built on top of lower-level constructs. So maybe arrays exist because they are the foundation and understanding them changes how you think about memory entirely.
That leads me to a bigger thought:
Maybe C++ keeps raw arrays not because they’re “better,”
but because C++ assumes the programmer should decide the trade-off.
Safety vs control.
Convenience vs precision.
Abstraction vs raw performance.
As someone early in the journey, I’m trying to figure out when those trade-offs actually matter in real-world development not just in classroom examples.
So here’s my question to experienced developers:
In what real production scenario would you intentionally choose a raw array over <code>std::vector</code> today?
And if you never would, why not?
Tomorrow I’m digging into functional decomposition and whether breaking everything into smaller functions actually improves clarity… or just makes code harder to trace.
Looking forward to your thoughts.

John Liter

A C++ student questions why raw arrays still exist when std::vector offers safety, dynamic sizing, and automatic memory management. The post explores trade-offs between raw arrays and vectors across dimensions like stack vs heap allocation, cache locality, embedded systems constraints, and legacy codebases. It concludes with a philosophical reflection on C++'s design philosophy of giving programmers control over trade-offs, and asks experienced developers to share real-world scenarios where they'd still choose raw arrays over vectors today.

Why Does C++ Still Have Raw Arrays?

I use arrays when i have a fixed size that i know will never change and doesn’t need any lookup aside from access via the index
And also when i don’t want to deal with copys vs references

You got most of it, but arrays are not (and should not) be limited to the stack. They can be there, since they are data types, but you can (and probably should if you intend to pass its contents around) ask for heap memory to store it. Other than that I think you are missing some important differences.
<code>vector</code> is a class, while an array (unless you are using the modern <code>array</code> class) is a basic data type. That means an array will need way less memory and be handled faster than a <code>vector</code>, which has some auxiliary data (at least it’s current size) and has to go through the calling of it’s methods to use.
Another important is that being able to change size is not a virtue by itself. Being able to handle size changes can be useful, but it is by no means free. To guarantee the temporal complexity similar to an array (as stated in the <a href="https://cppreference.com/w/cpp/container/vector.html" target="_blank" rel="noopener nofollow">docs</a>) the <code>vector</code> stores its data the same way an array, as contiguous memory; this means when you append an element that exceeds its current capacity it has to copy the whole internal array to a new location in memory with enough space to fit the new content and then some to amortize potential future size changes.
In brief, this are two data structures with their own roles and advantages. If you know the size will be fixed, using an array (even the <code>array</code> class) will always be more performant both time and memorywise. If the collection size will not be fixed you have to consider your other needs, a <code>list</code> might be a better use case if you do not need constant access to the contents of the collection.

When working on safety critical systems there are often requirements that prohibit the use of dynamic allocation. In those instances, you would not be able to use a vector and would need to use a raw fixed length array.

For example if you have an inventory system with 30 slots, you’d make an array that can hold 30 values instead of one that can be dynamically expanded