----- Original Message -----
From: "Joel de Guzman" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 8:53 PM
Subject: Re: [boost] Formal review: Optional library
>
> ----- 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.
>
You can certainly do the same with variant. The point is that with
optional<> it is *easier*.
With optional<> you don't need to specify the type of the wrapped value all
the time as with variant; and you don't need to explicitly test if the
variant holds a "nil_t" in order to see if it is initialized.
Fernando Cacciola
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
