*
pv**********@gmail.com:
[top-posting]
Don't top-post. See the FAQ. Corrected (also corrected the quoting).
* pv**********@gmail.com: * Andrew Koenig: * pv**********@gmail.com:
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.
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
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
