Path: utzoo!attcan!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: Packing Across Inheritance Boundaries is Currently Allowed.
Keywords: C++ packing layout structures
Message-ID: <56731@microsoft.UUCP>
Date: 20 Aug 90 16:46:33 GMT
References: <1990Aug3.211414.23872@watmath.waterloo.edu> <1086@lupine.NCD.COM> <2051@key.COM>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 21

>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.
>

...given that "reorder" simply means that within an access specified group
members declared later have to have higher addresses.  A compiler faced
with derivation could pack-in members of the derived class into a base
class - as long as the order is not violated.  But its easy to imagine
how compilers *would* need to change member order in order to pack-into
a base class.  Again, what does the currect restriction on field ordering
buy a C++ user?  It certainly *does not* guarantee compatibility with 
C structures!  So why not remove this restriction, and leave it up to
C++ vendors to choose their C-backwards compatibility trade-offs?