Why can a union have a member with a copy constructor?

[Peter Olcott]

Why can a union have a member with a copy constructor?

 

[puzzlecracker]

Why can a union have a member with a copy constructor?

Because it's not a class. In other words, Bjarne Stroustrup says so,
as well as Dennis Ritchie, and we, paltry followers, endorse it.

 

[Peter Olcott]

So then for only arbitrary and capricious reasons, not
functional reasons?

 

[PeteOlcott]

How do you know when that specific union member should be constructed?

What do you think should happen when two or more union members have
constructors?

You should be able to figure out the answer to your questions, by yourself.

If a class includes a union the class could also include a member that
indicates which element of the union is intended. In this case I see
no reason why this class that includes a union could not have a copy
constructor.

Carrying this same idea further this single member could be the first
element of a union of structs. In this case the union itself could
directly support a copy contructor, because this first element would
always indicate which of the structs is intended.

 

[Ian Collins]

If a class includes a union the class could also include a member that
indicates which element of the union is intended. In this case I see
no reason why this class that includes a union could not have a copy
constructor.

That's because there isn't one. This isn't the same as a union
including a class.

Carrying this same idea further this single member could be the first
element of a union of structs. In this case the union itself could
directly support a copy contructor, because this first element would
always indicate which of the structs is intended.

No, a union has no such concept. The first member of a union of structs
is often used to indicate which member is in use in C code. But that's
just a form of poor man's polymorphism. We don't need to use tricks
like than in C++.

 

[James Kanze]

First, the above statement is more or less wrong. An object
with a non-trivial copy constructor cannot be a member of a
union. (The next version of the standard will loosen this
restriction somewhat. And obviously, an object with a trivial
copy constructor can be a member of a union.)

Because it's not a class.

A union is a class. It's a very special type of class, but
according to the standard, it's a class.

In other words, Bjarne Stroustrup says so, as well as Dennis
Ritchie, and we, paltry followers, endorse it.

The problem is the compiler generated copy constructor. What
should it do if a member has a non-trivial copy constructor,
given that it doesn't know which member is active? The
standards (both C and C++) restricts union members to the cases
where a simple bitwise copy will work. This isn't the case for
an object with a non-trivial copy constructor.

And of course, it's no issue in C, since the copy semantics of
all types corresponds to a trivial copy in C++.

 

[James Kanze]

Now that's what I call a snotty response. It was a perfectly
valid question. All the more so as the restriction is being
lifted in the next version of the standard, so it obviously
wasn't necessary.

If a class includes a union the class could also include a
member that indicates which element of the union is intended.

Only one member of a union is active at a time. What do you do
when it isn't the member which indicates which element is
active.

It would have been possible to define yet another type
(generally called a discriminated union), which would be more or
less a struct with the union and an indication of which element
is active. There was some talk about it when the (C++) standard
was being developed, but I don't think it ever got to the point
of a formal proposal. (You'd also want a possibility of
interrogating the type, etc.) The general feeling then was, I
think, that this was basically already supported by a pointer to
a base type and dynamic_cast.

In this case I see no reason why this class that includes a
union could not have a copy constructor.

As I said, the next version of the standard will allow
objects with non-trivial copy constructors as members. If the
union has such a member, however, the implicitly defined copy
constructor will be absent, and either the user provides a copy
constructor (which is legal even now), and has some means of
knowing which object is active, or the union cannot be copied.

Carrying this same idea further this single member could be
the first element of a union of structs. In this case the
union itself could directly support a copy contructor, because
this first element would always indicate which of the structs
is intended.

You're basically trying to reinvent discriminated unions. It
can certainly be done---other languages do it. But it does
require a lot of specification.