David Fang wrote:
>
> <$.02>
> It's not highly techinical to see the fundamental difficulty with
> mixing ctor/dtors and unions. At the core of C++ is the association with
> constructors as initialization actions at the beginning of an object's
> lifetime, and likewise destructors associate with actions take at the end
> of lifetime. C++ defines the actions precisely: PODs (including pointers)
> need no action, objects of classes invoke their (in-charge) destructors.
> From this, it is evident that a union of PODs poses no problems. As soon
> as you have destructors, the language gives no automatic means of deciding
> which destructor (if applicable) to call. How would you make the compiler
> Do The Right Thing (TM)? Until unions are automatically tagged/embedded
> with type information, the language simply doesn't support proper
> destruction of non-trivial unions. You can find other dialects of C or
> C++ that do support this. Any dialect that adds these semantics cannot
> really be a trivial extension of C++.
> However, as others have hinted, it is not impossible to emulate
> tagged unions in C++, if you are willing to pay the bookkeeping overhead.
> (Surely you must know *somewhere* in your program what's what...)
> If you wrap your union in a class with a type enum, you can create a
> lookup-table/switch-case of member type destructors to invoke in the
> destructor of the wrapped class. Placement delete (counterpart of
> placement new) is used for in-place destruction. Some reinterpret_cast
> may come in handy if you're really into abusing the type system.
> </$.02>
A proper C++ style fix would require the introduction of new syntax rather
than tagging unions or such. The dominant ctors would have to be specified,
or unions themselves could simply be allowed ctors that override the member
ctors. Call them constructor overloads or something, no new syntax or
revolutionary semantics, just a quick and easy fix.
In the meantime, I don't see why a quick and easy workaround shouldn't be in
order, especially in light of all the microsoft originated code which should
be able to compile on linux where the issue is more than what the
preprocessor can handle, and its not some farout platform specific
extension.
--
View this message in context:
http://www.nabble.com/I%27m-sorry%2C-but-this-is-unacceptable-%28union-members-and-ctors%29-tf3930964.html#a11155996
Sent from the gcc - Dev mailing list archive at Nabble.com.
