Re: [boost] Improving the assignment operators of various Boosttypes

Subject: Re: [boost] Improving the assignment operators of various Boosttypes
From: David Abrahams (dave_at_[hidden])
Date: 2008-09-10 16:13:13

on Wed Sep 10 2008, "Giovanni Piero Deretta" <gpderetta-AT-gmail.com> wrote:

> On Wed, Sep 10, 2008 at 9:30 PM, David Abrahams <dave_at_[hidden]> wrote:
>>
>> on Wed Sep 10 2008, "Giovanni Piero Deretta" <gpderetta-AT-gmail.com> wrote:
>>
>>> If you do not want to deal with move emulation (which I've found very
>>> brittle in complex expressions),
>>
>> Do you mean the old-style move emulation that relied on T(T&) copy ctors
>> (known to be brittle) or does this assessment apply also to the
>> adobe-style emulation
>> (http://stlab.adobe.com/group__move__related.html)?  If so, could you
>> explain in more detail?
>
> The former; I have yet to try the latter. I got interested in the
> boost::move because it supported move only types (which IMHO are the
> really interesting application of move semantics). 
> Too bad that
> doesn't seems to be a robust solution in C++0x.

Move-only types aren't too interesting or difficult to write in C++0x,
actually.  Have you looked at
http://svn.boost.org/trac/boost/browser/trunk/boost/ptr_container/detail/static_move_ptr.hpp
?

>>> a simple way to to gain the advantage
>>> of T::operator=(T rhs) even when assigning from lvalues is something
>>> like:
>>>
>>>    template<class T> T destructive_copy(T& x) {
>>>       using std::swap;
>>>       T result;
>>>       swap(result, x);
>>>       return x;
>>>    }
>>
>> This only works when T is both default constructible and has an
>> optimized swap.  The latter is detectable, roughly speaking, so the
>> function could be altered to handle it, but the former is not, which it
>> seems to me makes destructive_copy not very useful in generic code.
>>
>> ...
>>
>>> For types which do not have an optimized swap is suboptimal, so some
>>> sfinae trick on is_swappable might be needed. Ah, of course it
>>> requires T to be DefaultConstructible, and most importantly
>>> CopyConstructible so it doesn't handle move only types.
>>
>> That's a lot of caveats.
>
> I think that the 'adobe move' has the same requirements. 

Only because they wanted those requirements anyway.

> OTOH, destructive_copy requires no specific support from the 'moved'
> type: a custom swap and the 'smart' operator= are useful on their own,
> so adding destructive_copy to one's set of tools requires very little
> extra baggage.

Very true.  For what it's worth, I had been working in this direction to
get move optimizations for C++03 when I discussed it with Daniel James a
few months ago, and I presume you're aware of this thread:
<http://news.gmane.org/find-root.php?message_id=%3cg8hj6n%24oud%241%40ger.gmane.org%3e>.

However, I prefer my assign(x) = y idiom for handling assignment on
non-move-or-elision-aware types.  See attached.  You can detect C++03
move/elision-awareness; combining that with this could be powerful.



-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com