[gclist] C++ proposal

[Charles Fiterman]

> Stefan Monnier, you wrote:
> > 
> > > A special and difficult issue is how to handle a union with a pointer
> > > and a non-pointer member.

> > I always thought that the 'definition' of "union" makes it semantically
> > equal to "struct". It's only the intended meaning which differs. In other
> > words, "union" is only a hint to the compiler that only one of the entries
> > inside the union will be used at a time.
> 
> You thought wrong.  There are a number of important semantic
> differences, including the requirement that all members of a union have
> the same address (or rather that the address of a union member, suitably
> converted, points to the union -- and vice versa.)
> 
> But even if you were right, it wouldn't make much difference, because
> the need for backwards binary compatibility would prevent C compiler
> vendors from radically changing their representation of unions.

The common address requirment is nowhere in the definition of C or C++.
However it should be! That is one of the reasons people use unions. Consider
the common function canon_long(long) which is used to convert longs to and 
from a common byte ordering for data protability. This generally depends 
strongly on unions and a common member address. It can hardly be written 
off as a bad programming practice.

Simply a C++ compiler that gave up common address semantics in union would
be considered unusable.