Boost logo

Boost :

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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at