8

I have the following code:

...
int n;
cin >> n;
int numbers[n];
...

It compiled with NetBeans on Mac using g++ (I think) and it didn't compile using VS2008 on Windows. Why is it so hard to make it work with every compiler? The size of the array is known before allocating it.

EDIT: I know about std::vector. Actually this was part of a homework assignment and I started it at work on a mac, then got home and was surprised that it didn't work on VS2008. Thanks for all the answers. But I still find it logical that if the compiler can generate some code like alloc(123) where the value 123 is hardcoded, why can't it generate something like alloc(n) where you get n from a memory address that holds an int n or something. It just seems more logical to allow something like this by default.

Sai Manoj Kumar Yadlapati
  • 330
  • 6
  • 22
gyozo kudor
  • 6,284
  • 10
  • 53
  • 80
  • 4
    why not use some cpp real stuff like `std::vector` for that –  Jul 24 '10 at 08:03
  • 1
    @RC: That's a good answer--make it a real one! – Drew Hall Jul 24 '10 at 08:07
  • 4
    This is a nonstandard C++ extension. Compile with `-pedantic` to have G++ flag it as an error. – Philipp Jul 24 '10 at 08:32
  • ["Variable-length automatic arrays are allowed in ISO C99, and as an extension GCC accepts them in C90 mode and in C++"](https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html) – phuclv Nov 18 '14 at 13:39

6 Answers6

16

Although the size of the array is known before it is allocated, it's still not known until runtime. This is known as variable length array (VLA) and is a C99ism, supported in g++ by an extension that is enabled by default. To be explicit, this is not conformant C++ 98/03, and thus Visual C++ is well within its right to reject it.

If you really want runtime dynamic sizing, allocate on the heap (via new[]). That will work everywhere, and as a bonus, protect you from stack overflows.

Drew Hall
  • 28,429
  • 12
  • 61
  • 81
  • 9
    Actually, don't use `new[]`. Use `std::vector`. – GManNickG Jul 24 '10 at 08:15
  • @GMan--I wholeheartedly agree! In my haste I neglected to mention that option, but don't want to cherrypick RC's answer at this point! :) – Drew Hall Jul 24 '10 at 08:18
  • I've had to work around this lack myself, though, while implementing data structure insert/delete algorithms. These are heavily used, including in inner loops, so definitely performance hotspots. I needed to build a "plan" (don't start changing nodes until you know the op will succeed - ensure self-consistency on failure). In the end I used a linked-list on the stack, built an item at a time using recursive calls (taking pains to minimise call overheads). A VLA would probably have been easier. –  Jul 24 '10 at 08:26
  • @Steve: That's hardcore! I probably would have used an extra std::vector data member in the data structure class to use as a working buffer. – Drew Hall Jul 24 '10 at 08:50
  • @Steve314: You can use alloca to roll your own VLAs. – Puppy Jul 24 '10 at 09:55
12

Because the size of an array must be a compile time constant in standard C++ (see 8.3.4 §1).

fredoverflow
  • 256,549
  • 94
  • 388
  • 662
12

why not use some cpp real stuff like std::vector<int> for that

2

Something similar can ne done with 

 int* numbers = (int*)alloca(n * sizeof(int));  // equivalent to int numbers[n]

this is not recommended function, but if used carefully, gives exactly the same result.

ruslik
  • 14,714
  • 1
  • 39
  • 40
  • 4
    And with carefully crafted input, the user can overflow the stack and score one for the bad guys. – Franci Penov Jul 24 '10 at 08:19
  • @Franci, don't you have nothing better to do than to design the "carefully crafted input" for this particular program? :) Better try http://www.crackmes.de – ruslik Jul 24 '10 at 08:56
  • 1
    There is an important difference between VLA and alloca(). VLA persist in their scope of declaration, while the alloca() block persists for the scope of the *function*. Declaring a VLA in a loop body uses therefore less stack as doing an alloca in the body. So if you learn about the required array size in the loop, alloca might not work for you. – Nordic Mainframe Jul 24 '10 at 09:14
  • 1
    @ruslik - part of what I am paid for is actually thinking about the potential effect of "carefully crafted inputs". :-) – Franci Penov Jul 24 '10 at 11:33
  • @Franci :)) Well, but in this case the security hole would be exactly the same as in "int numbers[n]", so you can't blame me for that ;) – ruslik Jul 24 '10 at 19:48
  • ah, but the other one does not compile in my world :-) – Franci Penov Jul 24 '10 at 20:30
  • then mine is better, because it at least compiles :) – ruslik Jul 24 '10 at 21:16
  • And as an old russian proverb says, an educated man is someone who knows how to play the bagpipe, but doesn't do it. – ruslik Jul 24 '10 at 23:45
2

By book the array dimension should be a constant expression whose value is greater than or equal to one. Constant expression in the sense integral literal constants, enumerators or const objects of integral type that are themselves initialized from const expressions. A non const variable whose value is not known until runtime can not be used to specify the dimension of an array.

But the compiler version i use allows the allows the way you mentioned.

josh
  • 13,793
  • 12
  • 49
  • 58
1

Support for VLAs is not present in Visual Studio 2008.

Michael Foukarakis
  • 39,737
  • 6
  • 87
  • 123