Re: [boost] Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-11 10:09:58

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Wednesday, December 11, 2002 10:21 AM
Subject: Re: [boost] Formal review: Optional library

> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
> > I still don't like to think of optional<> as a container, so I still
don't
> > like this reset.
>
> I don't see why. reset() has nothing to do with containership; it's a
> generic shorthand for reconstructing an object in place.
>
> void X::reset(args)
>
> Effects: destroys the contents of *this (if any)
> Postconditions: *this is equivalent to X(args)
>
OK.

>
> > Currently, you can change the value of the optional directly without any
> > performance
> > penalty like this: *opt = new_val, so I don't see any real need for
> reset().
>
> Not correct, *opt has undefined behavior when opt is uninitialized.
>
Funny...
The truth is that *opt has defined behaviour even if it is uninitialized
when
used as an lvalue: it can be reset to initialized.
IOWs, *opt=x is exactly like opt.reset(x).

This is clearly documented, clearly shown on the examples,
but apparently, clearly wrong :-)
(otherwise, you and William wouldn't have mistaken it)

I'll post a sub-thread to discuss this (mis?)feature on its own.
It has important derivations, such as the need for the proxy and
hence .value().

I think that if this behaviour is removed, the interface proposed by William
might work fine.

Fernando Cacciola