Variable Length Arrays

[sergent]

I don't get why ISO don't include VLAs in C++ standard. C++ is supposed to be a C extension, and C99 clearly supports VLAs. It is not hard to implement and does not break any existing C++ code. It is useful for beginners, who do not yet know pointers, and may look more attractive for programmers from other high-level languages. Also, many compilers support it, even through it is not standard, so it creates more compatibility issues with C AND people who use it anyways with C++.

Some argue that it is "bad" because it allocated memory from stack (as opposed to dynamically allocating it from the heap) so it can overflow it, but why can't they just make it use the heap instead of a stack, and just make it short way of typing VarType *x = new VarType[VarSize]?

[Zssffssz]

From what I'v read in books and stuff it seems as if using the stack pust more pressure on RAM and the makers of C++ wanted programer to do what with memory. That is one reason that people hate java.

[arkoenig]

What would you do with variable-length arrays that you can't do better with C++ vectors?

[mike_2000_17]

Scott Meyers started a huge discussion on usenet about this topic, pretty much all the arguments you can think of there find you will.

The gist of the argumentation is that there are too few use-cases and the changes required to implement them in C++ are pretty big and deep. Basically, people argue that: 1) if you don't have a reasonable upper-bound for the size of the VLA, then you should use a dynamic array (on heap) or an STL container (like std::vector); 2) if you have a reasonable upper-bound, then you could simply use a static array with that upper-bound size and simply use a subset of it (e.g. have an STL-like container whose storage is a static array of fixed maximum size). And thus, the compelling use-cases are few and far between.

Then, you have to consider that even though C and C++ share many similarities, the type system is fundamentally different. C++ enforces stricter rules on types (i.e. it is more strongly typed than C). C++ also has a lot more compile-time mechanism, like sizeof , decltype , alignof , etc., whose behaviour would be deeply affected by the presence of one type whose true identity and size are not known at compile-time (currently, in C++, all types are resolved at compile-time, and many features depend on that). I'm not a good enough expert to really know all the changes that VLAs would trigger, but I know they would be significant and far reaching. Also, in C++, the relationships between arrays, different types of arrays and pointers, are not realized exactly the same as in C (the differences are subtle, but make the handling of VLAs even more difficult). For example, what would this yield:

#include <iostream>

template <typename T, std::size_t N>
std::size_t array_length(T (&)[N]) {
  return N;
};

void print_array_length(std::size_t N) {
  int my_vla[N];
  std::cout << "The array length is: " << array_length(my_vla) << std::endl;
};

int main() {
  print_array_length(10);
  return 0;
};

Even if VLAs existed, there is no way that the above could be allowed to compile, but on what basis could the compiler refuse to compile it? In C, there are only very limited compile-time mechanisms, nothing like C++'s templates and other compile-time operators, and so, you don't encounter conundrums like the one above (or others like decltype(my_vla) ) which makes VLAs a feature that is a lot easier to add to the language than it is in C++. And the lack of any alternative besides malloc is a very compelling reason to introduce VLAs in C (while in C++, there are more alternatives than you could possibly imagine).

[sergent]

What would you do with variable-length arrays that you can't do better with C++ vectors?

Can't pass it as parameters to C functions (or any other laguages).
Can't make it faster.
Can't be compatible with C99 programs.

Using your logic, why don't we remove static and dynamic pointer arrays from C++?

Scott Meyers started a huge discussion on usenet about this topic, pretty much all the arguments you can think of there find you will.

The gist of the argumentation is that there are too few use-cases and the changes required to implement them in C++ are pretty big and deep. Basically, people argue that: 1) if you don't have a reasonable upper-bound for the size of the VLA, then you should use a dynamic array (on heap) or an STL container (like std::vector); 2) if you have a reasonable upper-bound, then you could simply use a static array with that upper-bound size and simply use a subset of it (e.g. have an STL-like container whose storage is a static array of fixed maximum size). And thus, the compelling use-cases are few and far between.

Then, you have to consider that even though C and C++ share many similarities, the type system is fundamentally different. C++ enforces stricter rules on types (i.e. it is more strongly typed than C). C++ also has a lot more compile-time mechanism, like sizeof , decltype , alignof , etc., whose behaviour would be deeply affected by the presence of one type whose true identity and size are not known at compile-time (currently, in C++, all types are resolved at compile-time, and many features depend on that). I'm not a good enough expert to really know all the changes that VLAs would trigger, but I know they would be significant and far reaching. Also, in C++, the relationships between arrays, different types of arrays and pointers, are not realized exactly the same as in C (the differences are subtle, but make the handling of VLAs even more difficult). For example, what would this yield:
C++ Syntax (Toggle Plain Text)
#include <iostream>

template <typename T, std::size_t N>
std::size_t array_length(T (&)[N]) {
return N;
};

void print_array_length(std::size_t N) {
int my_vla[N];
std::cout << "The array length is: " << array_length(my_vla) << std::endl;
};

int main() {
print_array_length(10);
return 0;
};
Even if VLAs existed, there is no way that the above could be allowed to compile, but on what basis could the compiler refuse to compile it? In C, there are only very limited compile-time mechanisms, nothing like C++'s templates and other compile-time operators, and so, you don't encounter conundrums like the one above (or others like decltype(my_vla) ) which makes VLAs a feature that is a lot easier to add to the language than it is in C++. And the lack of any alternative besides malloc is a very compelling reason to introduce VLAs in C (while in C++, there are more alternatives than you could possibly imagine).

Then how (or rather why), does G++ has VLA? VLAs are hard to implement for the reasons you mentioned earlier, so why would GCC implement this rather harmful thing into their compilers? It decreases code compatibility between compilers!

[sergent]

I just think VLA should be implemented for backward compatibility with C code. It can be regarded "evil" the same way gotos are in the community. It will be used only by complete beginners, and C code (neither of them will need templates or any other C-specific things). Pointer allocated dynamic arrays do not return sizeof array to (but the size of the pointer) so if they make VLAs they may neither implement it either.

[mike_2000_17]

>>I just think VLA should be implemented for backward compatibility with C code.

I think that the standard committee has been less and less preoccupied with backward compatibility with C. I think the C support rational can be summarized as: "if new C++ features can be realized without breaking C features, they will, but if C features have to be broken (or left unsupported) in order to implement 'superior' C++ features, they will be broken". The introduction of the "class" keyword instead of "struct" (which are essentially similar in C++) to not interfere with the definition of "struct" in C is a good example of the former, while the "auto" keyword in C++11 is a good example of the latter.

I know that some people like to think that C++ should be strive to be a super-set of C. It was the main opinion in the 80s. Now, there isn't as much motivation to do so, because very few people still see C++ as a super-set of C, and if anything, they see the backward compatibility for C provided by C++ as a low priority. Since C is also moving further away from C++ in its own way (VLAs, built-in complex numbers, and upcoming C1x features), I think it is time for you and many others to accept the divorce of C and C++.

>>It will be used only by complete beginners, and C code

I would teach beginners to use std::vector (and I have never seen a beginner so concerned about performance that he would require an option that uses a variable-length array allocated from the stack (which VLAs aren't even required to be btw)). You don't teach someone to program in C++ by having him write retarded C-style code.

As for C code, it is so easy to link C and C++ binaries together that I don't see much purpose for being able to compile C code with a C++ compiler. Adding VLAs to C++ isn't really about being able to compiler C code with a C++ compiler, if you want to write C code, compile it with a C compiler.

>>Pointer allocated dynamic arrays do not return sizeof array

That's because pointers are not arrays! That is the problem with VLAs, they are neither a pointer nor an array. In C, the distinction is very loose, but in C++, the distinction is very clear.