Re: Anonymous union rules against constructors & assignment
Crosbie Fitch wrote:
<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.
But you said it would have the same effects as the corresponding struct
you showed, which does involve default constructor calls. I think you
might want to come up with some way of describing what you want to have
happen, that doesn't involve that comparison with a struct type.
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?
I'm saying that if you allow non-POD types in your union, they either
run the risk of not having their constructors called, or of having
constructors called for overlapping objects without an intervening
destructor call. One of the key advantages of C++ over C is the
guarantees it provides about automatic construction and destruction of
objects, and I don't think it's a good idea to extend C unions to allow
members to have types for which those guarantees are both desireable
and impossible to provide.
..
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.
And for non-POD types, that violates the design of C++. Any object with
a non-trivial constructor should have that constructor called. Using
placement new to invoke the constructor is a hack. It's a necessary
hack, and I wouldn't recommend that it be dropped from the language,
but every time you use it you should be asking yourself whether there's
any other way to do what you want; if the answer is yes, it's probably
a better way of doing that task. Allowing non-POD types in unions only
becomes workable by use of placement new, or equivalent mechanisms.
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.
No. I'm saying that the implementation is ALLOWED to implement non-PODs
in such a way that, for some reason or another, there's no number that
sizeof could return for which memcpy(&target, &original, sizeof
original) will result in a correctly working copy of 'original' being
stored in 'target'. Looking at your definition of 'S', I can't imagine
any reason why they would want to do so in this case, but the standard
says that if an implementation did decide to do so, it would be legal.
The key point is that the standard provides no basis for deciding which
non-POD types have meaningful sizeof values, and which ones can be
safely memcpy()d. A prudent programmer therefore doesn't even try to
guess; when working with types that are, or at least might be, non-POD
types, the prudent programmer uses copy assignment or copy construction
to copy objects of those types.
How about this one:
template <class POD>
struct Empty: POD
{
Empty& operator=(const Empty& e) { PODMethod(e); }
};
Anything which renders a class a non-POD type gives an implementation
license to implement it in ways that render sizeof meaningless and
memcpy dangerous. An implementation isn't required to do so, but the
fact that it's permitted should be enough justification to avoid
relying on sizeof and memcpy for non-POD types.
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.
Could you explain that chain of inference?
---
[ 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 ]