Re: Anonymous union rules against constructors & assignment
<johnchx2@yahoo.com> wrote in message
news:1149784035.285474.311920@h76g2000cwa.googlegroups.com...
You *still* don't understand. The standard is butting in because its
intent is to enable implementations to invent object models other than
the C object model. That means that non-C objects (i.e. non-PODS) must
be systematically handled differently. The intent isn't merely to
force you to use the assignment operator, it's to enforce agnosticism
about the whole underlying object model.
Actually, I'm not challenging this at all. What I'm asking for is not in
conflict with the compiler doing what the heck it wants to non-POD objects.
It can represent them as 128bit location sensitive hash codes for all I
care.
I'm suggesting that the union behave in two different ways depending upon
its members.
1) An anonymous union with all POD members
2) An anonymous union with at least one non-POD member
I'm not asking for the first case to be changed at all. It'll be as safe as
it ever was.
The second case can be introduced - with safe ramifications, i.e. that no
default construction/copying/destruction occurs, and that a class containing
such an anonymous union becomes non-POD, and is obliged to perform this
construction/copying/destruction.
Call it 'overlay' if you want. A rose by any other name smells just as
sweet.
Now, you may believe that that choice was a bad one, and that the POD
object model is the only one that implementations should have been
allowed to use, just as you believe that the decision to allow trapping
union implementations was a bad one. Very well. You are entitled to
your opinion.
I'm not in dispute with this at all. No point in trying to portray my
opposition to this as it simply doesn't exist.
While we're on the subject, can I just say that not everyone shares
your view that type safety is for newbies, students and amateurs. The
attitude that "type safety is for the weak and foolish" isn't going to
improve your chances of getting what you want.
Again, I've not said this.
I'm against prohibiting non-POD members in unions instead of entrusting the
programmer to manage their lifecycle. The latter can be done safely, just as
writing a smart pointer can be done safely, however, though both are fraught
with risks and gotchas and it is rare to see a flawless implementation,
that's no reason to deny these things to programmers, i.e. on some holy
mission to reduce defects by keeping programmers away from things that might
lead them into temptation to try things not intended for mortal beings.
Although C++ is sacrifices type-safety in some places, it never does so
without reason, and the accepted reasons just about always boil down to
three:
(a) compatibility with C (typically limited to PODs where possible,
because C is limited to PODs, and the C object model applies to PODs)
(b) impossible to enforce typesafety without whole program analysis or
(c) allows you to do something which is both obviously useful and
impossible any other way
I'm not sure that any of the three generic exceptions applies here.
C - But whether 'properties' are obviously useful tends to polarise people
into antagonistic camps.
This is *much* better, for a couple of reasons. First, it focuses on
what you want, not on why the committee is foolish or paternalistic for
not providing it in the first place. Second, it detaches the rules for
overlaid storage from the rules for unions, and explicitly says that
it's syntactic sugar for raw storage. (Which, I know, is what you
think unions should have been in the first place, but they aren't .)
Well I contend that that is what they were in the first place, but they've
been shoehorned into an unsafe, unselected, doppelganger unable to lead a
worthwhile independent existence. A bit of a frankenstein's monster.
C++ introduced anonymous unions (A VERY GOOD IDEA), but then hamgstrung them
by hobbling them as named unions were (which I can concede is safe IF
unhobbled anonymous unions can take their place).
I'm still doubtful about how such a proposal would be received, though,
simply because how to work with overlaid storage is -- I think --
considered a solved problem in C++.
That's why there's no reason why an anonymous union with non-POD members
shouldn't also enjoy overlaid storage.
I've show the basic implementation
technique elsewhere in this thread (unions of aligned_storage objects),
and boost::variant illustrates one way in which the technique can be
wrapped up in a reusable class for a more convenient syntax (plus
complete type safety, for free!). Naturally, a solution built directly
into the language might have a somewhat more convenient syntax than a
library-based solution.
Somehow I don't think the boost::variant is quite the same thing as an
anonymous union. I could allocate memory and use re-interpret cast myself if
I wanted a variant.
struct Complex
{ union
{ float f[2];
M<Complex> magnitude;
};
Complex(float a,b);
};
1) sizeof(Complex) = 2*sizeof(float)
2) M<Complex>::operator float() { return sqrt(...); }
3) M<Complex>::operator=(float f) { sets the magnitude to f };
Notice how magnitude takes up no additional storage and yet provides an
additional read/write property of a complex number?
The two floats could have been magnitude and direction, with x and y pseudo
properties instead. The exposed member variables of the class do not dictate
the implementation (I'd prefer private access modifiers, but hey, can't have
everything).
I can use
Complex c; c.x=123.f; c.magnitude=55.f;
I don't believe the boost::variant can do the same job as the anonymous
union can above. Unless you or anyone else knows differently.
---
[ 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 ]