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

From: Joe Gottman (jgottman_at_[hidden])
Date: 2005-02-15 20:35:30

"Fernando Cacciola" <fernando_cacciola_at_[hidden]> wrote in message 
news:cute52$2g5$1_at_sea.gmane.org...
>
> "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.
>

   I disagree.  This may ensure the basic exception-safety guarantee, but 
most code that uses optional<T> will use T::operator=() at some point or 
other.  So if T::operator=() is not exception-safe, chances are good any 
program that uses optional<T> will not be exception safe either, regardless 
of whether optional<T> is.  Thus, you are not gaining too much.  And you are 
losing the strong exception safety guarantee when T::operator=() has it.  I 
think you are much better off implementing optional<T>'s assignment from T's 
rather than using the destroy and recreate idiom.

Joe Gottman