🚀 go-pugleaf

Dirk Becker wrote:
> 
> Hello, C++ gurus!
> 
> 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:

	I agree, I wrote a proposal to fix this. And, three countries
voted AGAINST adding yet another restriction to the list (references)
causing the motion to be withdrawn -- and then reintroduced
at a later meeting when two of the NB's were unable to send a delegate
for financial reasons.

> a)  "A union shall not have base classes. A union shall not be used as
>      a base class."

	This is in clear contravention of the clause that
says a union is a class -- and says that classes can have bases.
IMHO.
 
> This prevents any construction like the following, where one would
> like to extend the union contained in some base class:
> 
> class GenericInterpreter {
>     union opcode {
>         short tag;
>         struct { short tag; short data; } op1;
>         struct { short tag; char* data; } op2;
>     };
> };
> 
> class SpecialInterpreter : public GenericInterpreter {
>     union opcode : public GenericInterpreter::opcode {
>         struct { short tag; long  data; } op3;
>         struct { short tag; float data; } op4;
>     };
> };

   This is a very interesting idea. I'd not thought about that.
 
> b) "An object of a class with a non-trivial default constructor
>     (_class.ctor_), a non-trivial copy constructor (_class.copy_),
>     a non-trivial destructor (_class.dtor_), or a non-trivial copy
>     assignment operator (_over.ass_, _class.copy_) cannot be a member
>     of a union,"
> 
> This is a major reduction of the restrictions found in ARM, where all
> kinds of constructors or assignment operators were excluded. 

	No. It is merely a more precise statement of the same
restrictions using more technical terminology.

> c) "A union can be thought of as a class"

	Beats me how this can be, in view of the above constraints.
 
> In my opinion, comparing the copy constructor/assignments to others, they
> are only special regarding their use by the implicitly defined memberwise
> copy constructor/assignment by outside classes. Here I can't find a reason
> why a member's custom copy methods should not be applicable instead.

       	Absolutely. I agree. The current restrictions are valid,
but the prohibition is in the WRONG PLACE.

	You SHOULD be allowed to put constructible objects
in a union. All this does is prevent the compiler generating
an assignment operator. So if you try to use it, you get an error,
and have to define your own.

> d) anonymous union
> 
> Why is there no anonymous struct? 

	The committee (as a body) does not find arguments for 
orthogonal design appealing. It is hard to demonstrate
why orthogonal design is good to those who have little
experience with orthogonal systems -- most of us,
considering the horrid systems we're forced to work with
most of the time.

	So, where Bjarne was able to provide good design
we are lucky, and where he did not have time, or did not
personally consider it important, or just plain
messed up, we do not -- with one exception: STL
(which is designed better than most parts of C++ itself).

	On a more interesting note: templates are
NOT powerful enough to fix this problem (brain dead
unions) BUT they are ALMOST enough. In conjunction
with a header file generator program, an emulation
of discriminated unions is available (mail me).
Also available the logical generalisation of
STL "pair" to order n.

	[I'm attempting to upgrade these facilities
so they work with FUNCTIONS as well as data structures.
There are some serious obstacles inherent in the
non-orthogonal core language design, preventing
higher order genericity from working. What I have
working currently requires a generator which produces
O(n^n) declarations. For example a struct of order
10 with associated generic operators is useable,
the header is about 1Meg. Much above that -- needed
in practical applications -- requires compiler
support to "generate when required"]


-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 web: http://www.maxtal.com.au/~skaller/
AUSTRALIA                      email: skaller@maxtal.com.au
---
[ 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. ]