Re: I'm sorry, but this is unacceptable (union members and ctors)

["michael.a" <wild dot eyed dot boy dot from dot freecloud at gmail dot com>]

If all you need is one memeber that has constructors / destructors, and
all other members are PODs that provide an alternate view of the contents,
then I think that would make a logical extension of the transparent union
extension.  A transparent union as passed to functions in the same manner as
its first member.  You could define that a tranparent union is allowed
to have as its first member a class with constructors and/or destructors,
and that these constructors / destructors are then the constructors /
destructors of the union.

Caveat: If the union is larger or more alingned than its first member,
the argument passing semantics don't make sense.  This is documented in
extend.texi:
  Second, the argument is passed to the function using the calling
  conventions of the first member of the transparent union, not the calling
  conventions of the union itself.  All members of the union must have the
  same machine representation; this is necessary for this argument passing
  to work properly.

There is also a syntax example for __attribute__ ((__transparent_union__))
in
extend.texi.  
Inside the compiler, you can check if union is a transparent union using the
TYPE_TRANSPARENT_UNION macro.

If the initial union member can be an anonymous struct, and rather than
expecting further members to be "POD" instead their ctors/dtors are simply
ignored, then that would work for anything I can come up with.



> 
> Try contrib/gcc_update --touch after the checkout.
> 
> 

This suggestion made some ground. But I just can't get a build to complete.
The newest checkout / release aren't compatible with my C libraries it
seems, and I'm not sure its safe dependency wise to just replace the C
libraries. So I rewound my subversion checkout to the same branch as is in
my debian distribution repository. That build gave up when it couldn't find
a directory called config/i386 I think it was. So I downloaded the same
major release as my distro just now (4.0.0) and this one is trying to access
the gcc/include directory with "../include" from "build*/liberty" which
obviously should be "../../include", so it gives up. I just can't win.


-- 
View this message in context: http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11184663
Sent from the gcc - Dev mailing list archive at Nabble.com.