Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: Order of fields within one section
Keywords: fields, sections
Message-ID: <56679@microsoft.UUCP>
Date: 17 Aug 90 19:02:24 GMT
References: <1083@fornax.UUCP>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Distribution: comp
Organization: Microsoft Corp., Redmond WA
Lines: 71

In article <1083@fornax.UUCP> miron@fornax.UUCP (Miron Cuperman) writes:
>Is the order of fields within a section preserved?

Yes.  According to E&S.  But, "preserved" only means that fields declared later
within a section come at higher addresses.   "Preserved" doesn't mean that
fields are adjecent, nor that they don't have anything else useful between
them, nor that they have the same packing characteristics as your favorite
C compiler.  [Although I'd certainly think that most vendors would want to
keep their C and C++ compilers pretty compatible for the next couple of 
years as people switch over.]

But, I'm lobbying to have this restriction eased so that C++ compilers aren't
constrained to be backwardly compatible with C a couple years down the road --
when backwards compatibility is no longer an issue.  And again, in any case,
for a C and a C++ compiler to be "compatible" a vendor is going to have
to make a conscious decision they want their C and C++ compilers to be 
compatible.  Field ordering is only a tiny part of this decision.  Removing
field ordering restrictions doesn't keep a vendor from making their C and
C++ compilers compatible.  Maintaining field ordering doesn't force a vendor
to keep their C and C++ compilers compatible.  In either case, its still
strictly an particular vendor's choice.  So I say, let's remove this silly 
restriction.

>For example:
>class C
>{
>private:
>	int size;
>	float a[0];
>}

No -- Array dimensions must be specified as being greater than zero.

>Is 'a' guaranteed to be after size 

Yes -- but "after" just means that a has a higher address than size,
not that they are next to each other.  And what it means to compare addresses 
of different types of things is also undefined.  So what does it mean to
be able to say a is "after" size ?

so I can do C *C1=malloc(sizeof(C)+n*sizeof(float));

Yes and No.  Yes such a statement is legal in the language.  But, no
it is not legal to then use C1 as you're planning to use it.  E&S 
specifically calls out the old C trick of writing off the end of a 
structure as being illegal.  [It was never even legal to write off the end of
an array in C]

Most C++ compilers today would generate code incompatible with this
hack if someone subsequently tries to derive from class C.

>If that is permissible, is it possible to use 'new' to allocate
>an arbitrarily sized object?

"That" is not "legal" --but is it "permissible"?  Most C++ compilers will permit
you to get away with it [given your array index is not zero.]  Just don't
try to derive from C, nor make an instance static, nor put an instance
on the stack....

....The obvious hack is to get a chunk of memory from new:

void *pv = new char[sizeof(C) + n*sizeof(float)]; // give or take one from n

then construct your object at the start of that chunk using placement
syntax:

C* C1 = new(pv) C(n);

---

Better yet, just don't do this hack, use a separate allocation for your array.