🚀 go-pugleaf

In article <1086@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
> In article <1990Aug3.211414.23872@watmath.waterloo.edu> gjditchfield@watmsg.uwaterloo.ca (Glen Ditchfield) writes:
> >I think that packing of classes is allowed by the current definition of
> >C++...
> Of course it is ALLOWED.  Lots of things are allowed.  That's not the point.
> The point is "What do the people who need inheritance-boundary packing to
> ALWAYS occur (regardless of which compiler they are using) do?"
> 
> If you are trying to write portable code, and you need the kind of
> packing that we are talking about, as of now you are out of luck because
> the closest thing that we currently have to a "standard" is E&S which
> does not specify a way to *force* this kind of packing to occur regardless
> of which "conforming" implementation you are using.

I agree that with the current standard, any form of packing is allowed, as long
as the compiler does *not* reorder fields *within* an access specified group
(between "public","private","protected",or end-of-class-definition).

E&S gives as rationale for this one constraint the compatibility with the
(usually) coexisting C system. The idea is that a straight C-style "struct"
declaration uses the same layout as when compiled by the C compiler (ANSI C
is explicit about structure field ordering - reordering is forbidden).
I don't think the *intent* of the C++ rule is to inhibit layout modifications
in complex C++ class hierarchies.  Certainly the *wording* does allow it.

However, Ron: if you want to write "simple portable" code (no customization,
no conditionals), you cannot possibly expect to dictate to the compiler (that
is *every* compiler) what layout strategy it should use. The compiler is
responsible for reconciling the language requirements with the oddities of
the hardware. The only thing you can resonably expect to specify is guidelines.
For example, "inline" does not mean "inline this, I know what's good for you".
It means, "I guess I'd prefer if you could inline this, if it's okay with you".
Likewise I don't see how you can "force" *every* compiler out there to conform
to your idea of optimal layout.

And yes, I can see how a "packed" attribute could make sense for a struct/class,
just like "inline" makes sense for functions. I'm beginning to feel worried
though about the number of "implementation directive" features people want to
add to the language. "Inline" makes sense as a keyword, because it slightly
changes the semantics of the program (see E&S for details).

May I point out that we have a general mechanism for compiler hints and
directives, inherited from ANSI C? Pragmas. Yes, I know they are not
portable. But I'd rather see a minimal set of pragmas that every implementation
should heed as described or ignore (as opposed to redefine), than another
five keywords in the language.
  -- perry
-- 
--------------------------------------------------------------------------
Perry The Cynic (Peter Kiehtreiber)		       perry@arkon.key.com
** What good signature isn't taken yet? **  {amdahl,sgi,pacbell}!key!perry