There recently was a discussion about this kicked off in usenet: Why no VLAs in C++0x.
I agree with those people that seem to agree that having to create a potential large array on the stack, which usually has only little space available, isn't good. The argument is, if you know the size beforehand, you can use a static array. And if you don't know the size beforehand, you will write unsafe code.
C99 VLAs could provide a small benefit of being able to create small arrays without wasting space or calling constructors for unused elements, but they will introduce rather large changes to the type system (you need to be able to specify types depending on runtime values - this does not yet exist in current C++, except for new operator type-specifiers, but they are treated specially, so that the runtime-ness doesn't escape the scope of the new operator).
You can use std::vector, but it is not quite the same, as it uses dynamic memory, and making it use one's own stack-allocator isn't exactly easy (alignment is an issue, too). It also doesn't solve the same problem, because a vector is a resizable container, whereas VLAs are fixed-size. The C++ Dynamic Array proposal is intended to introduce a library based solution, as alternative to a language based VLA. However, it's not going to be part of C++0x, as far as I know.
+1 and accepted. One comment though, I think the safety argument is a little bit weak since there are so many other ways to cause stack overflows. The safety argument could be used to support the position that you should never use recursion and that you should allocate all objects from the heap.
So you're saying that because there are other ways to cause stack overflows, we might as well encourage more of them?
@Andreas, agreed about the weakness. But for recursion, it takes a huge number of calls until stack is eaten up, and if that can be the case, people would use iteration. As some people on the usenet thread say, though, this is not an argument against VLAs in all cases, since sometimes you definitely may know an upper bound. But in those cases, from what i see a static array can equally be sufficient, since it would not waste much space anyway (if it would, then you would actually have to ask whether the stack area is large enough again).
Also look at Matt Austern's answer in that thread: The language specification of VLAs would probably considerably more complex for C++, because of the stricter type matches in C++ (example: C allows assigning a
T(*)[]to aT(*)[N]- in C++ this is not allowed, since C++ does not know about "type compatibility" - it requires exact matches), type parameters, exceptions, con- and destructors and stuffs. I'm not sure whether the benefits of VLAs would really pay off all that work. But then, i have never used VLAs in real life, so i probably don't know good use cases for them.@AHelps: Perhaps what would be best for that would be a type that behaves somewhat like
vectorbut requires a fixed LIFO usage pattern and maintains one or more per-thread statically-allocated buffers which are generally sized according to the largest total allocation the thread has ever used, but which could be explicitly trimmed. A normal "allocation" would in the common case require nothing more than a pointer copy, pointer-from-pointer subtraction, integer comparison, and pointer addition; de-allocation would simply require a pointer copy. Not much slower than a VLA.