From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-02-15 16:25:48
"Peter Dimov" <pdimov_at_[hidden]> escribió en el mensaje
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk