Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!nsc!amdahl!key!perry
From: perry@key.COM (Perry The Cynic)
Newsgroups: comp.std.c++
Subject: Re: Order of fields within one section
Summary: Another common non-portable practice
Keywords: fields, sections
Message-ID: <2053@key.COM>
Date: 17 Aug 90 18:40:41 GMT
References: <1083@fornax.UUCP>
Reply-To: perry@arkon.key.COM (Perry The Cynic)
Distribution: comp
Organization: Key Computer Laboratories, Fremont
Lines: 52

In article <1083@fornax.UUCP> miron@fornax.UUCP (Miron Cuperman) writes:
> Is the order of fields within a section preserved?
> For example:
> class C
> {
> private:
> 	int size;
> 	float a[0];
> }
> 
> Is 'a' guaranteed to be after size so I can do
> 	C *C1=malloc(sizeof(C)+n*sizeof(float));
> 
> If that is permissible, is it possible to use 'new' to allocate
> an arbitrarily sized object?

The order of fields within a section is guaranteed to be preserved by the
compiler (says E&S). You are guaranteed that "a" follows "size" in the
storage layout of the class. But that doesn't help you.

The compiler is perfectly entitled to place stuff *after* a[0] (there is an
explicit warning to that effect in E&S) If class C has virtual members, you
have a good chance that some compiler out there (perhaps yours) will put its
virtual table pointer at the end of the class, totally screwing up your scheme.
This is not portable C++, nor is it good C++, though it is a common practice
in the C world.

One possible solution is to change your class definition into
	class C {
	public:
		C(int n);
	private:
		int size;
		float *a;
	};

	C::C(int n) {
		a = new float[n];
	}
which is (I hope) perfectly portable. You can add appropriate access functions
to your class (including, if you wish, a float& operator[]).
Depending on your particular situation, you may then be able to allocate objects
of type C as static or auto variables, or members of other structures. If you
can do that, performance will actually be improved (because accesses to the
size member don't need indirection). This requires a somewhat different way
to look at C objects (value-oriented vs. reference-oriented), but I find it
to be rather useful.
  -- perry
-- 
--------------------------------------------------------------------------
Perry The Cynic (Peter Kiehtreiber)		       perry@arkon.key.com
** What good signature isn't taken yet? **  {amdahl,sgi,pacbell}!key!perry