Re: Anonymous union rules against constructors & assignment
"Crosbie Fitch" wrote:
<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.
What I really meant to say is that I'm surprised you didn't use
new(&u.b) B(123);
However, the struct case you gave also requires that B have an
accessible default constructor, so that's not really a difference
between the two cases.
However, there is an issue with default constructors, I just didn't
raise the issue correctly. The struct case you gave calls the default
constructors for both A and B (if any). I'm curious what rules you're
proposing for the handling of unions of non-POD types, that would
produce that same sequence of constructor calls. I can imagine rules
that involve one call to A(), two calls to B(), and one call to B(123).
I can imagine another set of rules that produces just one call B().
However, I can't come up with reasonable rules that produce one call to
A() and one call to B(), which is what would happen in the struct case
you game. You said those two cases should have the same behavior.
Except when the default constructors for both A and B are no-ops, that
doesn't seem possible. And, when they are non-trivial, it's quite
dangerous, since it would result in two different objects being
constructed in the same memory without an intervening destructor call.
..
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).
That's what the POD rules are for. I thought that you wanted that
restriction removed?
Has no-one considered that a class may be designed precisely with a view to
its appearance within a union?
For non-POD types, C++ has abolished every guarantee that makes it
useful to view it through a union. In particular, the fact that
memcpy() is only required to work on POD types, and that sizeof() is
only required to produce meaningful results on POD types, allows an
implementation where the memory in which a non-POD object is stored is
non-contiguous.
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).
I'm talking about classes with non-trivial assignment copy operators,
where copying them bit-wise could be a whole lot more dangerous than
that. It's precisely because memcpy() won't do the right thing that the
class has a non-trivial assignment copy operator.
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?
No, you described that as a delusion, and I was agreeing with you.
However, your wording implied that someone has actually promoted that
delusion. I was just asking you who that was.
---
[ 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 ]