[boost] Re: [bug]: optional<T> fails on self-assignment

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-02-15 13:16:26

"Fernando Cacciola" <fernando_cacciola_at_[hidden]> escribió en el mensaje 
news:cutcrj$tcb$1_at_sea.gmane.org...
>
> "Joe Gottman" <jgottman_at_[hidden]> escribió en el mensaje 
> news:curjg1$2vq$1_at_sea.gmane.org...
>
>> [SNIP]
>
>> It has the added advantage that if T's assignment operator has the strong 
>> exception safety guarantee, so does optional<T>'s assignment operator.
>
> Well, this is a good point.
> It is typical for classes with a throwing copy ctor to have a strong 
> assignment.
>
OK, I was sure there was a good reason why I didn't use T's assignment to 
begin with.
I just didn't remeber it when I responded.
The idea is that by using T's operator=() we are _entirely_ left to its own 
exception guarantees, with no guarantee at all from optional<T> itself.
The current implementation gives you the basic guarantee, which is more than 
enough in most cases, no matter how ill T could be: if something goes wrong 
while reseting the value of *this, it is left uninitialized.

So the correct path is to add the cannonical guard AFAICS.

Cheers

Fernando Cacciola