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@boostpro.com> 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/sta... ?
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