Why doesn't C++ support dynamic arrays on the stack? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 14 years ago.

In C99 this was legal:

void f(size_t sz) {
 char arr[sz];
 // ...
}

However, this - dynamically sized stack arrays - has been dropped in C++, and not seeing a return in C++11.

AFAIK C++ was made with C compatibility in mind, so I wondered There must be some very good argument of not including this useful feature, right?

All I could think of was this:

Pros

• Memory savings by allowing smarter array sizes that need to be on the stack (temporary buffers?).
• Less "smart pointers" (or worse, manual bug-introducing delete []'s) and slow heap allocations.
• Compatibility with C99.

Cons

• Allows people to easily allocate too large arrays on the stack giving hard-to-debug stack overflows.
• More complicated for compiler writers.

So, why did they didn't they include it when they imported other C99 features?

---

To prevent this from being closed as "subjective" or "not constructive", I'm looking for quotes from commitee members or links to discussions talking about the matter - with bonus points for a quick SO roundup of course.

Rather than seeing this as a Ponies vs Hamsters discussion, see it as a historical question, mere interest in the advantages and disadvantages that were considered (if at all).

---

EDIT: As James McNellis pointed out in the comments below C++ existed before C99 standardized variable-length arrays. You might read my question then as: "Why didn't and won't they add it?".

• James McNellis: It hasn't been "dropped" because it was never part of C++.
• Omnifarious: BTW, this seems to me like a clear question with a definite answer. It doesn't seem subjective, and while the term 'dropped' is a bit loaded and not entirely accurate, I think that's a minor nit.
• user541686: I'm kind of surprised that people get so fond of closing "Why?" questions as "subjective". IMHO, many of the best questions on StackOverflow are indeed the "Why" questions. (See here.) Just because multiple people can have multiple guesses as to the answer doesn't mean that there isn't a right answer. I think people should chill down a bit and allow questions like this to go on, instead of closing them on the spot just because they can't think of an objective answer. :\
• tenfour: The reason for closing questions is to preserve the quality of content on SO. Of all the crappy questions that remain, how is this question generating this much controversy? Just leave it open; it's helpful and interesting.
• Omnifarious: This isn't a bad question because it's subjective, it's bad because it's a duplicate. :-)

Answer 1

I think, it's because C++ provides superior solutions: std::vector<T> and std::array<T,N> (C++11); though the latter is not dynamic as such but it's superior to raw arrays. You can always know the size, no matter which function you pass the vector or array.

Since C cannot provide these solutions, C99 came up with Variable Length Array (VLA). It has the same problem as regular arrays: it decays into a pointer on passing it to function, and you no longer know the size of the array.

And as Florian Weimer asked here at comp.std.c++ that if C++0x allows VLA, then what would the following code mean?

int vla[n]; //n is known at runtime!
std::vector<decltype(vla)> v; //what does this mean?

How is the compiler going to instantiate the vector template at compile-time when it's type argument depends on n which is known at runtime?

• Omnifarious: If you -1 something, it's only polite to say why.
• Sarfaraz Nawaz: @Downvoter: please specify the reason so others and me can know why this answer is silly; and how it can be improved.
• orlp: This is a valid answer, if you disagree don't just blindly downvote but say in the comments. Please read the tooltip of the downvote button: "this answer is not useful". I disagree with that on this particular question.
• rafak: I didn't -1'ed, but I don't agree "C++ solutions are superior": maybe they are in a lot of contexts. But after having profiled carefully a piece of code I recently had to write, the only sensible options were a static vector or gcc's VLA extension, to avoid too frequent heap allocations. I chose vector for portability, but this left me with a not thread-safe function (which is waiting for "thread_local" implementation). In this case, knowing the size outside of the function was uneeded, and VLA was superior to std::array (btw, i couldn't understand why std::array was so slower than VLA).
• Marcelo Cantos: @Nawaz: std::vector<T> initialises its elements, which may incur an unacceptable performance hit in some cases. The decltype issue is a red-herring; the compiler could simply disallow it, as does the Objective-C++ compiler: Variably modified type 'decltype(a)' (aka 'int [n]') cannot be used as a template argument.

Answer 2

This functionality largely duplicates that of std::vector, except that it consumes a more limited resource (stack vs heap space). As such, there is not really any need for it in C++, semantics-wise.

One could argue that on-stack allocation can improve efficiency (particularly in the face of multiple threads); however, this can also be achieved in C++ using custom allocators to build a private memory pool, either on the stack or heap. This is again more flexible than placing memory on the stack, and indeed you could create a custom allocator that carves chunks out of an on-stack memory buffer easily enough. It's not exactly the same as dynamic array semantics, but the existence of custom allocators and STL containers covers most use cases you'd want stack allocation.

• Omnifarious: Was there a discussion to that effect? One thing that comes to my mind is that stack space is automatically thread-local, and that can be a very useful thing because it makes allocating stack space very fast as compared to allocating heap space on many implementations. But I can understand if that fact was considered and found not compelling. I'm just curious.
• user541686: @bdolan: Stack space is O(1) speed allocation, which is great for things like file names (which are around ~256 characters max). Heap allocations are comparatively much slower, and applications that work with small strings could often greatly benefit by using the former instead of the latter. So I'm personally not convinced that there isn't a "need" for it in C++. (Otherwise, why do compilers implement _alloca so often?)
• bdonlan: I don't know if this was actually discussed in the standardization process, but it seems a reasonable reason to exclude it. Yes, local allocation can be marginally more efficient, but a lot of malloc implementations have thread local pools anyway, and for larger allocations, the cost of construction exceeds that of allocation anyway.
• bdonlan: @Mehrdad, std::string implementations often have small strings allocated within the object anyway...
• James McNellis: @Mehrdad: The Visual C++ 2010 std::string implementation uses the small-string optimization.