> My general opinion is it serves no one to be regressive about extensions.
> You can always advise against using them, and somewhere down the road, the
> specs can always decide an extension is worth supporting more conservatively
> or adding to a future spec altogether.
>
> It would be interesting for someone to try to make a practical argument that
> is anything but a nest of technicalities, as to why ctors and unions
> shouldn't be mixable.
Hi,
<$.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>
> In the meantime, I've always intended to hack the bugger (in the always
> bandied about GNU tradition) if I must. It bothers me though to think that
> no one has charted this territory before.
David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)
