Boost logo

Boost :

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" <> wrote:

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

Move-only types aren't too interesting or difficult to write in C++0x,
actually. Have you looked at

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

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

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