Re: [boost] Formal review: Optional library

From: Joel de Guzman (djowel_at_[hidden])
Date: 2002-12-10 18:53:22

----- 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.

Joel de Guzman
joel_at_[hidden]
http://www.boost-consulting.com