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

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

"Peter Dimov" <pdimov_at_[hidden]> escribió en el mensaje 
news:003201c51395$4f587820$6501a8c0_at_pdimov2...
> David Abrahams wrote:
>> Jody Hagins <jody-boost-011304_at_[hidden]> writes:
>>
>>> 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;
>>> }
>>>
>>
>> I wish people would stop calling it that.  It's easy, but it's
>> overkill.
>
> No, it is not overkill. It is the easiest way to implement a correct 
> assignment operator. Forget performance. Subtle bugs in assignment are 
> notoriously hard to find. To give the "canonical" example:
>
> optional& operator=( T const & t )
> {
>    // destroy and recreate
> }
>
> Consider what happens when an optional holds a tree node and is assigned a 
> child of that node. Or in general, when the 'destroy' step indirectly 
> destroys the right hand side.
>
Well, I would be surprise if T were so unlike a POD to have this sort of 
issues... but well,  who knows. I would recommend shared_ptr<> in that case, 
but, well, maybe genericity get's in the way.

I just looked closer at optional_swap() and it offers no exception-safety 
guarantees at all...
It just does whatever T's swap() does.
operator=() was designed to give a basic guarantee in spite of T.

Thus, as I replied to Joe, changing the implementation means loosing the 
basic guarantee and leave it up entirely to T...
I'm not sure how much good or bad that is... but I do remember that it was 
designed like that on purpose after long discussions here.. or at least 
that's what I concluded from those discussions ;)

> A correct assignment operator should typically handle self-assignment 
> without an explicit test. Adding the test usually doesn't fix the problem, 
> only its most obvious manifestation.
>
Which could be accounted as good enough for classes intended to be used in 
certain ways, thus making the swap idiom overkill.

Fernando Cacciola