-1

Why is it so important for dimensions of the array to be initialized from constexpr? Would a regular variable in a code bellow imply(if allowed legal) possible resizing of the array in the future?

int a=5;
int arr[a];
a=10;
Alan Stokes
  • 18,815
  • 3
  • 45
  • 64
Misha.P
  • 300
  • 1
  • 2
  • 9
  • 1
    C99 added support for this, called *variable length arrays*, or VLAs. They don't fit well the C++ type system. In particular, `sizeof` is compile time always in C++. – Cheers and hth. - Alf Jun 08 '16 at 21:52
  • What do you think the type of `arr` is? Note that the type must be known at compile time and also note that the size of an array is part of its type. – Kevin Jun 08 '16 at 21:53
  • The array size is part of the *type*. So everybody who sees `int[a]` must see the same type. Imagine you had `using T = int[a];`. What would that mean if `a` could change? – Kerrek SB Jun 08 '16 at 21:53
  • Uhm, the type could be just `int arr[]`, if VLAs were supported. As I recall there was a proposal to add C99 VLA, and if so then the problems are not unsurmountable. It's just very ugly for very little gain. The current variable length proposals are at higher level, I believe. Hiding the core language support under some library abstraction. – Cheers and hth. - Alf Jun 08 '16 at 21:55
  • @Kevin, yes, I know that it must be known at compile time, but does it mean that regular variable is not "processed" until runtime? – Misha.P Jun 08 '16 at 21:56
  • 1
    C++ already has a standardized portable variable-length array, it is called `std::vector`. The only difference between a `vector` and a VLA is that the `vector` allocates its array on the heap, whereas a VLA allocates its array on the stack instead (allocating variable-length data on the stack is dangerous, which is why `_alloca()` was never standardized). VLAs are a vendor-specific compiler extension for those that want to support it. – Remy Lebeau Jun 08 '16 at 21:57
  • @RemyLebeau; No, the closest you get, but non-portable (especially in how failure is detected and reported), is `alloca`. The current variable length array proposals would not make much sense if `vector` did the job. It doesn't: it uses costly dynamic allocation. – Cheers and hth. - Alf Jun 08 '16 at 21:58
  • 2
    @M.Pak No. The compiler cannot know the value of a non-const variable in the general case. So it doesn't try to figure out in specific cases like this. You need a constant (literal), const, or constexpr. – Kevin Jun 08 '16 at 22:01
  • @Kevin, thank you, that's what I was wondering about. Is there a description of some kind, documentation maybe, of what compiler does or does not? – Misha.P Jun 08 '16 at 22:05
  • Why would you expect `int arr[a]; a=10;` to resize the array? If something can take a variable it can take a return value, so how would you expect `int arr[getvalue()]` to work in that universe? (Some compilers do implement VLAs and allow `int a = 1; int arr[a]` but they dont' resize the array when you change a. – kfsone Jun 08 '16 at 22:07
  • @kfsone: It probably comes from a mathematical point of view. It's not an unreasonable expectation before one learns more about the language and how it works under the hood. I remember when I first learned Pascal, that must have been 1982, our textbook said that a `while` loop terminated when the continuation condition became false. That gave me the impression that there was a continuous checking of the continuation condition. Some languages work in ways like that, but not Pascal. The book was also unclear about `with` statements. It's like the authors *assume* knowledge of machine code. – Cheers and hth. - Alf Jun 08 '16 at 22:12
  • @Cheersandhth.-Alf In C, `int arr[a];` does not allow resizing , the size is fixed at the value `a` had when execution reached this declaration – M.M Jun 08 '16 at 22:14
  • @M.M Thank you for trying to clear that up. :-) – Cheers and hth. - Alf Jun 08 '16 at 22:15
  • Just use `vector`. – Alan Stokes Jun 08 '16 at 22:15
  • @kfsone, I am not familiar with underlying processes that array undergoes during initialization, so I suspected it might just happen because of the strong use of pointers in C++. And as for return value as initialization value: I think a plain variable is somewhat more obscure than that, for when compiler might not be able to process a function, it still, in my head, might easily check something as `int a=3;` – Misha.P Jun 08 '16 at 22:18
  • @M.Pak _"it still, in my head, might easily check something as int a=3; "_ But what about other cases like `cin >> a`? Should language complexity be increased by declaring when compiler should, might or should not analyze code to determine if value is known at compile time? How deep it should process? So to not burden already complex language, there is a requirement for array initializer to be a constant expression in language standard. – Revolver_Ocelot Jun 08 '16 at 22:32
  • Possible duplicate of [Variable-length arrays in C++?](http://stackoverflow.com/questions/1887097/variable-length-arrays-in-c) – uh oh somebody needs a pupper Jun 08 '16 at 22:41

1 Answers1

1

Such a feature was proposed in n3497 but scrapped before C++14. C and C++ are completely different languages. Their syntax may be similar, but their evolution has diverged quite a bit. C++ aims to be more type safe and excise features that are dangerous or useless (like auto_ptr).

A C++ "VLA" wouldn't be very useful anyways, to name a few features explicitly excluded from the proposal:

  • multidimensional arrays, where other than the top level has a runtime bound (in analogy, array-new doesn't support that either)
  • modifications to the function declarator syntax
  • sizeof(a) being a runtime-evaluated expression returning the size of a
  • "typedef int a[n];" evaluating "n" and passing that through the typedef

And undoubtably many more situations. C++ has a specification that's twice as large as C99 and then some, imagine the flood of bug reports for "why does this Quirk work" or "why doesn't this Quirk work" or "is this Quirk legal?" because of people trying to shoehorn VLAs everywhere.

And the paper even calls out a common criticism of VLA's:

Stack overflow becomes more likely, in particular if the size depends on external input and is not properly checked. Some environments might therefore prohibit the use of the feature. Such a prohibition can be easily enforced with a static analysis tool.

Imagine the amount of careless crap code that will be written if this was a feature. You may argue that in C++, you can shoot yourself in the foot. But C++ tries to at least adjust your sights so that the point of impact is the floor and not your foot.

What should you do instead?

Use std::vector. Got complaints about performance for a simple program? You're prematurely optimizing.