sizeof Arrays

[anugrah]

While working with arrays I came across this piece of code:

int n;
cin>>n
int a[n];

And this works perfectly fine. However, I have been reading in many c+
+ textbooks that the size of an array should be known at compile time.
But the above code proves it to be wrong. Can anyone pls explain this
anomaly?

Moreover I have been declaring:

static int a[5];

And I am able to access elements of a[ ] indefinitely (i.e. with array
indexes even more than 5) without any sort of error. Please explain me
this phenomenon too.

 

[dmtr]

While working with arrays I came across this piece of code:

int n;
cin>>n
int a[n];

And this works perfectly fine. However, I have been reading in many c+
+ textbooks that the size of an array should be known at compile time.
But the above code proves it to be wrong. Can anyone pls explain this
anomaly?

Well, it is sort of known. It is n * sizeof(a[0])...

 

[Stefan van Kessel]

While working with arrays I came across this piece of code:

int n;
cin>>n
int a[n];

And this works perfectly fine. However, I have been reading in many c+
+ textbooks that the size of an array should be known at compile time.
But the above code proves it to be wrong. Can anyone pls explain this
anomaly?

Moreover I have been declaring:

static int a[5];

And I am able to access elements of a[ ] indefinitely (i.e. with array
indexes even more than 5) without any sort of error. Please explain me
this phenomenon too.

In C99 variable-length arrays (VLA) were introduced to C and GCC has an
extension that allows their use in C++, too. In C++ it's not standard
conform though and other compilers will fail - rightly so. Just use a
std::vector instead.

When you access anything with an index higher than 4 in the second
array, the behavior is undefined. That doesn't mean you'll necessarily
get any kind of observable error but you'll read some more or less
random memory and you'll likely run into a segfault sooner or later. One
possible reason for you not having gotten one yet is that if you just
write e.g. a[32904]; Without actually doing anything with the retrieved
value that has side-effects the compiler is very likely to just optimize
it away.

Have a nice day,
Stefan

 

[Kai-Uwe Bux]

While working with arrays I came across this piece of code:

int n;
cin>>n
int a[n];

And this works perfectly fine.

Chances are that you are using g++, which compiles this piece of code as an
extension. Use the -pedantic option to get the diagnostic that is required.
It will still compile the code, but at least it issues a warning telling you
that the code is illegal: "ISO C++ forbids variable length array 'a'"

However, I have been reading in many c++ textbooks that the size of an
array should be known at compile time.

The books are correct.

But the above code proves it to be wrong.

It doesn't. The code proves your compiler to be buggy (more precisely, it
demonstrates the need to invoke your compiler with the appropriate command
line options to get standard conforming behavior).

Can anyone pls explain this anomaly?

Moreover I have been declaring:

static int a[5];

And I am able to access elements of a[ ] indefinitely (i.e. with array
indexes even more than 5) without any sort of error. Please explain me
this phenomenon too.

Such access beyond the bounds of an array is what the standard calls
"undefined behavior": no diagnostic is required (neither at compile time nor
at run time) and anything might happen at run time. _Anything_ in particular
includes behavior that you might expect. Such undefined behavior can easily
go undetected.


Best

Kai-Uwe Bux

 

[Juha Nieminen]

In C99 variable-length arrays (VLA) were introduced to C and GCC has an
extension that allows their use in C++, too. In C++ it's not standard
conform though and other compilers will fail - rightly so. Just use a
std::vector instead.

Note, however, that a variable-length array will in most compilers be
significantly more efficient than std::vector (especially if the function
is called very frequently). This is because these compilers allocate the
array on the stack, which is an extremely fast operation (while std::vector
allocates the array on the heap, which is quite a heavy operation with
most compilers).

You could also use the alloca() function (defined in <alloca.h>) for the
same purpose, but this is also a gcc extension, so it's probably even less
portable. (And, like malloc(), it won't construct the elements, so you
have to be careful if using it with anything else than primitive types.)