🚀 go-pugleaf

kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

>dirk@becker.adviser.com (Dirk Becker) writes:
>
>|> In Section 9.6.1 Unions [class.union] there is a large collection of
>|> restrictions on the union itself and on candidate member classes.
>|> I would like to ask for reasons of several of them:
>
>One of the principle goals was that a union be compatible with a C
>union, at least in use.  One of the rules is that the addresses of all
>of the elements in the union compare equal to the address of the union
>itself, when cast to the appropriate type.
>
>|> a)  "A union shall not have base classes. A union shall not be used as
>|>      a base class."
>
>Without this rule, you either break the address rule, or you impose
>some special class layout on unions.

Nevertheless, contrary to what you seem to be implying,
that rule is not necessary for C compatibility.

C++ structs can be very different to C structs, but C compatibility
is preserved for a certain category of C++ structs, namely POD-structs.
In the case of unions, the same thing could have been done -
rule (a) could have been dropped, yet C compatibility could still
have been be supported for POD-unions.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]