Array size as constant expression

[pvinodhkumar]

The number of elemets of the array, the array bound must be constant
expression?Why is this restriction?

Vinodh

 

[Victor Bazarov]

The number of elemets of the array, the array bound must be constant
expression?Why is this restriction?

Because it's better (easier) that way.

 

[pvinodhkumar]

Easier in case of the compiler implementation?
Is it that difficult?I really don't know.

 

[Andrey Tarasevich]

The number of elemets of the array, the array bound must be constant
expression?Why is this restriction?

Firstly, because the current object model of C++ language requires that
sizes of objects with static or automatic storage duration is known at
compile time. Memory layout for static and automatic memory in C++ is
determined at compile time. In order to do that the compiler needs to
know the sizes of all objects, including arrays. (This condition was
weakened in new C - C99, but it is still there in C++).

Secondly, there's no such requirement for dynamic objects. For this
reason, array size in 'new[]' expression is not required to be a
constant expression.

 

[Victor Bazarov]

Easier in case of the compiler implementation?
Is it that difficult?I really don't know.

What would be the size of an object which as a member has an array whose
size is unknown? How do you work with an object of an unknown size? How
do you access other members of such object? All of those offsets have to
be decided at the run-time. Can you imagine the overhead it will cause?

 

[Andrew Koenig]

The number of elemets of the array, the array bound must be constant
expression?Why is this restriction?

Because the size of an array is part of its type and C++ types are fixed
during compilation.

 

[pvinodhkumar]

But why there is no such restriction while allocating in heap?

 

[pvinodhkumar]

But why there is no such restriction while allocating in heap?

 

[Alf P. Steinbach]

* (e-mail address removed):

[top-posting]

Don't top-post. See the FAQ. Corrected (also corrected the quoting).

* (e-mail address removed):

* Andrew Koenig:

But why there is no such restriction while allocating in heap?

A C++ is a low level structure that directly is a contigous area
of memory -- in contrast to an array in e.g. Java or C#, which
is a fixed size pointer that points to some data structure which
might or might not be a contigous area of memory (doesn't matter).

In short, in C++ there's minimal abstraction between your array and
the raw memory, nothing that intercepts your stated operations.

Now consider the two basic ways an array can be allocated:

* As part of another object.

* Not as part of another object, i.e. free-standing.

When created as part of another object that object's memory layout
is fixed at compilation. More precisely, the offsets from the start
of the object to the start of each member are fixed at compilation.
So unless the array is the very last member it must be of fixed
length -- a variable length would change the offsets of the following
members at run-time, and so play havoc with the code that assumes fixed
offsets (again this is due to no intervening abstraction layer).

Summing up: part of another object -> fixed length, unless last member
of the object (this last possibility for variable length is offered as
a language extension by some compilers, but isn't supported by the std.).

Then consider the three ways an array can be allocated when it's not
defined by you as being part of another object:

* Statically (either outside any function or using the word
'static' inside a function).

* On the stack (local variable).

* On the heap.

If it's statically allocated then, although you haven't specified that
it's part of another object, at the level of memory layout it is: it's
squeezed in between the other static objects, which can't have their
offset from the start of static storage changed at run-time -- the
very same situation as for object members.

Static allocation -> fixed length, unless it's globally the last static
object (which there's no way to ensure), so the standard simply
requires fixed length.

With allocation on the stack there is technically the possibility of
dynamic length, because the stack is a dynamic data structure, and that
is supported in C99, and offered as a C++ language extension by some
compilers. Also, some compilers offer a run-time library function that
lets you allocate dynamically on the stack (of course in last-in-first-out
fashion). But standard C++ doesn't support either feature, at least not yet.

I'm not sure why that was decided, but original C was a comparably simple
language, and did not offer features that did not have very direct benefit.

Finally, with allocation on the heap there's no allocation-related problem,
because heap allocation at bottom already is a function that must be ready to
deliver any number of bytes of contigous storage, with n specified at runtime.
The only problem is that the number of array elements must be dynamically
recorded somewhere, in order to support destructor calls for the elements.
In C++ that's supported because dynamic heap allocation of arrays was
supported in C (that didn't have the destructor call issue), it would be
silly if C++ was more limited than C in that regard, and most important it
would have made the language nearly unusable -- it's that critical.

Hth.,

- Alf

 

[Andrew Koenig]

But why there is no such restriction while allocating in heap?

Because what gets returned is a pointer to the initial element of the array,
not the array itself, so the size does not participate in the type.