Variable length arrays (VLA) in C and C++

Question

Possible Duplicate:
Variably modified array at file scope

I have some concepts about the VLA and its behavior that I need to clarify.

AFIK since C99 it's possible to declare VLA into local scopes:

int main(int argc, char **argv)
{
    // function 'main' scope
    int size = 100;
    int array[size];
    return 0;
}

But it is forbidden in global scopes:

const int global_size = 100;
int global_array[global_size]; // forbidden in C99, allowed in C++

int main(int argc, char **argv)
{
    int local_size = 100;
    int local_array[local_size];
    return 0;
}

The code above declares a VLA in C99 because the const modifier doesn't creates a compile-time value. In C++ global_size is a compile-time value so, global_array doesn't becomes a VLA.

What I need to know is: Is my reasoning correct? The behaviour that I've described is correct?

I also want to know: Why the VLA in global scope aren't allowed? are forbidden both in C and C++? What reason is there for the behavior of arrays into global and local scope were different?

Answer 1

Yes your reasoning is correct, that is how these different forms of array declarations and definitions are viewed by C and C++.

As others already stated, VLA with a veritable variable length (non-const) in global scope is difficult to make sense. What would the evaluation order be, e.g if the the length expression would refer to an object of a different compilation unit? C++ doesn't have VLA, but it has dynamic initialization of objects at file scope. And already this gives you quite a head ache, if you have to rely on evaluation order.

This leaves the small gap for C concerning length expressions that contain a const qualified object, which isn't allowed. This comes from the fact that such objects are not considered "integer constant expressions" by the C standard. This could perhaps change in future versions, but up to now the C committee didn't find it necessary to allow for such a thing: there are enum constants that play that role in C. Their only limitation is that they are limited to int in C, it would be nice to also have them size_t.

Answer 2

C++ doesn't support VLAs, period. The reason the second code snippet works in C++ is that the const keyword creates a compile-time constant in C++; in C, it doesn't.

C99 doesn't support VLAs outside of block scope, period, regardless of how you declare the size variable. Note that C2011 makes VLA support optional.

Answer 3

There is a difference between being forbidden and not being allowed. ;-)

The VLA feature is designed to allow the use of stack space for a local array, to avoid the use of malloc for heap allocation. It is mostly a speed optimization.

Now you want to use VLAs outside of functions. Why? There is not much to win speedwise in avoiding a single malloc call during program start. And what stack space are we supposed to use for variables with a static life time?

Answer 4

I think the fundamental reason is a global variable has linkage, its size has to be known at compile time. If not, how could one link the program?

local variables have no linkage and the VLAs are allocated on the stack, which grows dynamically as the program runs.

Answer 5

So, for global VLA's, one of the issues (there are many variants on the theme) can be shown here:

int size;
int a;
int v[size];
int b;

.... in another file:

extern int a;
extern int b;

The linker will have to know where a and be are in relation to each other at link time, or it won't be able to fix them up correctly at load-time.