$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2006-11-06 07:31:01
David Abrahams wrote:
> I'm just looking through the variant library docs in detail and had
> the following commments:
Ah, if only boost::variant was actively maintained...
I had several issues raised in
http://listarchives.boost.org/Archives/boost/2006/06/105801.php and some time
later I encountered another issue - I think the default constructor for
variant is a bad idea. The thought came to me after I made a mistake of
writing
typedef variant< optional<X>, optional<Y> > SomeType;
when I really meant was
typedef optional< variant<X, Y> > SomeType;
later in my code, thinking I had the right typedef, I constructed an
instance of SomeType using its default constructor, assuming I had an
empty optional<variant> in my hands, while I actually had a variant with
an empty optional<X>. Unfortunately, it compiled, and that mistake was
only found in run-time, with the help of the QA department.
If variant didn't have a default constructor, my mistake wouldn't have
compiled. IMO, this is also true from a more theoretical point of view -
there is no reason to favor one of the variant types (the first one)
over the others. Those types are basically equivalent and symmetric. If
the user wishes to add a default constructor himself, he can derive from
the variant, and add such a constructor, favoring the type of his
choice. Or maybe the best solution would be to add a template parameter
to boost::variant to indicate which of the types to use for the default
constructor, with an option (the default one) to not supply a default
constructor at all.
Of course I'm just saying all this here for Google's sake. Nothing real
would probably be done. Sad...
Yuval