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

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

"Jody Hagins" <jody-boost-011304_at_[hidden]> escribió en el mensaje 
news:20050215103732.03af02c0.jody-boost-011304_at_atdesk.com...
>
> Actually, there are multiple assignment operators, with different levels
> of complexity and "bugginess."
>
Care to detail these levels of "bugginess"?
Only one of the assignment overloads suffers from the self-assignment bug 
anyway.

>It seems to me that implementing the
> canonical assignment operator would work fine...
>
>
> optional & operator=(optional const & rhs)
> {
>  optional tmp(rhs);
>  optional_swap(*this, tmp);
>  return *this;
> }
>
The purpose of this idiom is provide a better exception guarantee based on a 
safe swap (preferably a non throw swap).
If the swap is no better (exception-safety-wise) than a straight assignment, 
the idiom is unnecesary.
It turns out that optional_swap gives only the basic guarantee, and so does 
assign(), so there is no point in this.

> This actually brings me to a more broad question...  with a fairly well
> accepted practice for safe implementation of assignment operators, some
> boost libs seem to go out of their way to implement something different.
> Is this because of perceived performance issues, or something else?
>
Something else: purpose.
The right idiom in the wrong place (or context) is a Bad Thing.

Best

Fernando Cacciola