Re: Anonymous union rules against constructors & assignment
<kuyper@wizard.net> wrote in message
news:1149702049.000782.69720@c74g2000cwc.googlegroups.com...
What I really meant to say is that I'm surprised you didn't use
new(&u.b) B(123);
For clarity. I wanted to demonstrate where the difference occurred, i.e.
that a union did not call the default constructor - that it must be called
explicitly - rather than simply prohibit a non-default.
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'm saying that a union should not attempt to construct its members.
If I have 10 members of a union, are you really suggesting to me that each
default constructor is called that coincidentally does nothing?
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?
I'm distinguishing between the union's constructor and the constructors of
the union's members.
The union's constructor should by default do nothing - which is currently
misportrayed as actually calling each of its members default constructors
which coincidentally do nothing.
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.
So, you're saying that if I have
struct S
{
int i;
S& operator=(const S& s) { i=s.i; }
};
that even if I was allowed to put it in a union, there's no way the compiler
can compute the size of S or allocate a large enough union to contain S?
That is one lousy compiler.
How about this one:
template <class POD>
struct Empty: POD
{
Empty& operator=(const Empty& e) { PODMethod(e); }
};
If the other member of the union is an instance of POD, why can't Empty
(which introduces the dreaded non-pod assignment and no additional members)
call a POD safe method on its POD base?
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.
Let's get this straight: I agree that memcpy() is not guaranteed to copy any
non-POD object.
I'm saying that irrespective of that, that's no reason to prohibit a non-POD
member within an anonymous union. Rather than prohibit it, simply say that
memcpying an anonymous union containing a non-POD member is undefined.
Moreover, you can say that a class that contains an anonymous union with a
non-POD member will not have a default assign-copy operator or copy
constructor (or default constructor or destructor).
However, your wording implied that someone has actually promoted that
delusion. I was just asking you who that was.
I inferred it from the restrictions governing unions and their members.
---
[ 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 ]