Re: Anonymous union rules against constructors & assignment
In article <fLGdnbqS3NJxmBXZRVny1g@bt.com>,
"Crosbie Fitch" <crosbie@digitalproductions.co.uk> wrote:
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 far more concerned when the types have non-trivial destructors.
Personally, I'd love to see the rules for POD-ness relaxed to any type
that has trivial destruction (where the destructor is empty, and the
destructors of all of its elements are also trivial). While
constructors are used mainly to set up class invariants, they are
sometimes used as a convenient way to initialize value classes
(especially when used in conjunction with templates). [To be fair, I
haven't looked to see if anyone has proposed such a thing.]
Alignment issues notwithstanding, wouldn't the following code get you
the behavior that you want (where C is the "union" of A and B):
struct A
{
int i;
};
struct B
{
char c;
};
struct C
{
union
{
char aMemory[sizeof(A)];
char bMemory[sizeof(B)];
};
A& a;
B& b;
C() : a(*reinterpret_cast<A*>(aMemory))
, b(*reinterpret_cast<B*>(bMemory))
{}
};
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 ]
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (773) 961-1620
---
[ 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 ]