Re: Anonymous union rules against constructors & assignment
<kuyper@wizard.net> wrote in message
news:1149623054.476991.128910@h76g2000cwa.googlegroups.com...
"Crosbie Fitch" wrote:
Apart from overlaid storage there should be no difference between:
struct S { A a; B b; } s; s.b=B(123);
and
union U { A a; B b; } u; new(&u.b) B(); u.b=B(123);
So a default constructor would be mandatory?
No. There would be no restrictions on what methods a member had or did not
have.
A union should have no default constructor or destructor.
A union should be thought of as an area of memory with size large enough to
contain its largest member. Accessing any member of a union should be
thought of as casting a pointer to this area to a pointer of the type of the
member.
Thus given A & B.
struct Union { char m[max(sizeof(A),sizeof(B))]; } s; // union { A a; B
b; } u;
u.a === *(A*)&s;
u.b === *(B*)&s;
You say that you're not assuming that the members are PODs. That means
(among other things) that they won't necessarily survive a bit-wise
copy.
Just as they wouldn't necessarily survive a reinterpret cast.
Until unions are permitted to have user defined methods like classes, the
defaults have to be the C defaults, i.e. no construction/destruction and
bitwise assign-copy (of the memory - not the members).
Remember that unions are esoteric in the first place and even in C often
needed external logic to interpret and manage their contents. There's every
reason to expect that in containing objects those objects will also need
external logic to manage their lifecycle. To instead require that any member
of a union must be treatable as a POD struct, but can otherwise have any
member functions, is unnecessarily blunting the knife for no good reason.
If anyone uses a reinterpret_cast or a union it should be a given that they
know precisely what they're doing, i.e. that "Thou shalt read no member that
thee hath not made good afore".
It is incredibly irksome they now require compilers to prevent (not just
warn) against having members with a particular member function (a
particularly useful one too).
Has no-one considered that a class may be designed precisely with a view to
its appearance within a union?
It is possible that a user defined assign-copy operator may be needed
precisely in order to avoid undefined behaviour.
Despite this fact, the union itself is to be copied bitwise.
Could you explain in a little more detail precisely how that's supposed
to work?
The union is large enough to contain the representation of its largest
member.
Copying a union bitwise by default is just as dangerous as a default
assign-copy operator for a class (with member pointers).
You've got to stop worrying about putting cotton wool on things. C++ is not
Smalltalk or Java.
By trying to make a union slightly safer it has become emasculated.
I'm curious - who expressed that delusion? That sounds like a
description of the implicitly-defined copy assignment operator for
class types, but it doesn't describe unions.
Are you really telling me that you believe that when copying a union each
member's default assign-copy operator is called?
I think you'll find that it's a simple bitwise copy of the union (with no
regard to the members).
"Oooh. But, what if someone has a pointer as a member? It might not be
valid to copy the pointer?"
"Well, if they don't know what they're doing they'll hurt themselves."
"Oooh. But, what if someone has a member object with a user-defined
assign-copy operator?"
"Ah. Yes. They're obviously clueless and we must put a stop to it before
they hurt themselves. It is our duty to make C++ a safer language than C"
So, now I have to go through the hoops:
class A
{
A& CustomAssignCopy(const A& a) { /*copy*/ return *this; }
public:
A& operator=(const A& a) const { return
const_cast<A*>(this)->CustomAssignCopy(a); }
};
union U
{
A a;
};
THAT IS PERMITTED and compilers quite happily compile it, the computer
doesn't burst into flames, the programmer doesn't burst a blood vessel and
the world doesn't end. But, it's a nasty hack and needs further hacks to
restore the const behaviour to const instances.
But, some hand-wringing goody-goody who didn't see significant use for
objects within unions in C++ put a spanner in the works in the name of
health and safety and said "Oooh no, because we can't see why unions should
be used for anything except POD we will make it a right pain for anyone who
tries - because anyone who tries probably doesn't know what they're doing".
In my case I'm not even wanting to exploit undefined behaviour. I need a
custom assign-copy operator precisely in order to ensure the correct
representation within the union is being assigned to.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]