From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-11 15:38:00
----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Wednesday, December 11, 2002 2:22 PM
Subject: Re: [boost] Formal review: Optional library
> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
> > Conclusion: I will adopt William's reset, leaving operator*() return
> > a reference to the optional value *only* if it is initialized
> > (independently of whether opt is const or not).
> > Therefore, the proxy is not needed. And so value() isn't needed either.
> > (B)
> > Since most reviewers wanted it, I will add a safe_bool idiom, which will
> > allow
> > conditional expressions like:
> > if ( opt )
> > if ( opt == 0 )
> > if ( opt != 0 )
> Can you please update the documentation to reflect the changes? I want to
> vote on the revised version. ;-)
Yes, but first look at my last post where I show the new interface entirely.
If that is more or less OK I'll update the documentation in order to
continue with the review.
> > However, I'm still unconvinced that uninitialized optionals should
> > false,
> > and even though, you can always compare optional values (via operator*),
> > I see no benefit in defining relational operators directly (thus these
> > operators
> > will be poisoned)
> I think that the proposed comparisons make a lot of sense.
Just to make sure I understand what you're saying:
Do you agree about having comparisons undefined for optionals directly
and only defined for optional values (i.e. *opt1==*opt2)?
> You should consider providing operator<<(std::ostream&, optional), too.
The idea is that if the optional is uninitialized, it outputs something like
else forwards to T::operator <<(), right?
I agree it is usefull, but I'm not sure if it should be provided by the
A user can define a sort of to_string() with whatever output he wants for
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk