----- Original Message -----
From: "Joel de Guzman" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 6:47 PM
Subject: Re: [boost] Formal review: Optional library
>
> ----- Original Message -----
> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
>
> > ----- Original Message -----
> > From: "Joel de Guzman" <[EMAIL PROTECTED]>
>
> > > Hi,
> > >
> > > Probably a dumb question but allow me to ask anyway:
> > >
> > > Wouldn't a more generic variant<T0, T1...TN> class do what the
> > > optional is trying to do? I feel that optional<T> is just a variant<T,
> > nil_t>
> > > in disguise. Correct me if I'm wrong.
> > >
> > The difference is that optional<> *explicitly* deals with the
possibility of
> > being
> > uninitialized, while variant<T,nil_t> doesn't. (for the later, nil_t is
just
> > another possible value).
> >
> > In this regard optional<> is more handy for its intended usage.
>
> 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)
Fernando Cacciola
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
