Re: [boost] Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-11 08:31:27

----- Original Message -----
From: "Joel de Guzman" <djowel_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Tuesday, December 10, 2002 8:53 PM
Subject: Re: [boost] Formal review: Optional library

>
> ----- Original Message -----
> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
>
> > > 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