$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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