🚀 go-pugleaf

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