Re: sizeof() calculated at compile time or run time
On Sep 18, 12:37 am, Vidar Hasfjord <vattilah-gro...@yahoo.co.uk>
wrote:
On Sep 16, 11:00 am, James Kanze <james.ka...@gmail.com> wrote:
On Sep 16, 8:26 am, Vidar Hasfjord <vattilah-gro...@yahoo.co.uk>
wrote:
On Sep 15, 10:09 pm, James Kanze <james.ka...@gmail.com> wrote:
VLA's don't have a known compile time size.
This and the other characteristics of VLAs makes them even
more peculiar than static arrays; which already is the most
striking type irregularity in C++. A VLA is not a first-class
object. It can only live on the stack; i.e. function scope.
That's not true in C, although there are some restrictions.
No. Declarations of VLAs must be at either block scope or
function prototype scope. A VLA cannot be extern, static or a
member.
Yes. The C standard seems to distinguish between arrays with a
variable length, used as local arguments, and arrays with a
variable length placed at the end of a struct; in the latter
case, it considers the array to have an incomplete type (which
it calls a flexible array member), rather than being a "variable
length array". I hadn't noticed that before; in my mind, they
were both variable length arrays (since both are used as
variable length arrays).
This has a number of repercusions, and definitely simplifies the
adaptation in C++, since most of the problems concern flexible
array members, and not what C calls variable length arrays.
Off hand, I don't see any problems with adopting this
definition of VLA directly in C++, without any changes from C.
But I imagine there are some; otherwise, I can't see why the
committee didn't do it. Flexible arrays pose all sorts of
problems with regards to inhertance, constructors and
destructors, assignment, etc. (Come to think of it, how does C
handle the problem of assignment?) Interestingly enough, sizeof
is a constant expression when applied to a struct with a
flexible array. Logically, this would suggest that sizeof
should always return 0 when applied to a VLA, but I guess the C
committee wanted to maintain the use of sizeof in array
addressing in the case of an array of VLAs.
It's also a question why the C committee didn't allow something
like:
struct A { int i; int j; double a[i][j]; } ;
There's no reason this can't be made to work, as long as it's
not an object with static lifetime, and it would seem very
useful.
See below.
It can certainly be aggregated in C, although it must be the
last element in a structure.
No. That is a flexible array member (FAM); also introduced in
C99. Flexible array members allow incomplete array struct
members without bounds; and must be the last member as you
say. See
http://www.comeaucomputing.com/techtalk/c99
So I see. I don't know why; I've always thought of them as more
or less the same thing. (Actually, I do know why; I was
influenced by another, very influent member of the C++
committee. Which may explain why the integration of VLA's
wasn't considered.)
Anyway, this point changes my opinion completely with regards to
VLAs. Without the problems which allowing them in a class
introduces, simple C compatibility should be enough of a reason.
(The traditional rule is "as close to C as possible, but no
closer". Unless there's a good reason for not being compatible
with C, we should be.)
As far as type is concerned it only decays to a pointer.
No. It has an array type.
My conclusion is that the VLA feature is more of an allocation
mechanism than a type.
Not at all, although from another posting, I gather that that is
what Alf really wants: not VLAs, but a type-safe alloca.
(Something which bears the same relation to alloca that the new
operator bears to malloc. Perhaps a special placement new?)
Rather than adopt VLAs, i.e. another irregular array type, I
think C++ should rather focus on a dynamic stack allocation
mechanism and find a way to make that accessible to any type.
Why? What does that buy us?
Not much... :-)
On the other hand, as long as the concept of VLA and flexible
arrays is well separated in C, the effort to add VLAs to C++
wouldn't have gone much beyond copy/paste. And they are useful
in the case of multidimensional arrays (which curiously, no one
in this thread has mentionned as a motivation): using
std::vector for a multidimentional array (except within the
implementation of your own multidimentional array class) is
exceedingly painful, and std::valarray doesn't seem to be widely
used either.
Of course, there is the problem that C style arrays are broken
to begin with. But off hand, even ignoring the performance (and
static vs. dynamic initialization issues), I don't see any good
alternative for multidimensional arrays. (But maybe I just
haven't looked hard enough. In my own work, I don't need them.)
My point is simply that if such an optimized allocation
feature is found to be wanted for C++, then C++ should look
for better (more regular) ways of achieving it. Automatic
compiler optimization would of course be the ideal.
I don't think that the optimization is that much of an issue.
Modern allocators can be very fast, and various other
considerations make variable stack allocation more and more
difficult. The real issue, IMHO, is multidimensional arrays.
Because let's face it:
std::vector< std::vector< double > >
a( 10, std::vector< double >( 20 ) ) ;
instead of:
double a[ 20 ][ 10 ] ;
really isn't very programmer friendly. (Also, of course, the
former cannot easily be passed to other languages, which
generally do have multidimensional arrays, and lay them out
contiguously in memory.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34