----- Original Message -----
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > Hmmm, I'm not sure if I agree with this. T can very well be
> > uninitialized in the variant when nil_t is in effect. Then
> > nil_t can just be struct nil_t {}; which costs nothing to initialize.
> > Why is optional "more handy" in this regard?
> >
> Because it has an interface that makes it easier to deal with its possibly
> uninitialized state:
>
> optional<int> opt ;
> int x = *opt ; // Oops! opt is uninitialied. In debug this is an assertion
> failure, in release, a core-dump.
>
> *opt = 3 ; // initializes it.
>
> if ( int* x = get(opt) )
> some(*x)
But of course you also have that interface with the variant.
Example:
if (p = variant_cast<int>(pvar))
...initialized
else
...uninitialized
or...
int n = variant_cast<int>(var);
// Oops! var is uninitialied. throws bad_cast
It's trivial to make that a free function like get. Or further, to make
a subset API for optional.
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
