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

Subject: Re: [boost] Improving the assignment operators of various Boosttypes
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-09-10 16:45:27

2008/9/10 David Abrahams <dave_at_[hidden]>:
>> 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.

D'oh! I meant C++03!

>
> 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
> ?

And from a quick glance at that code, I see no rvalue references, so I
think you understood what I meant and not what I wrote :).

I'll take a deeper look at that code.

>
>>>> 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.
>

Yeah, I just read your link to  Daniel James simple extension to the
adobe move. I'll have to try it.

>> 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.

It looks nice, expecially for standard containers whose operator=
doesn't pass by value.

-- 
gpd