Daniel James
On 8 July 2013 13:25, Joaquin M Lopez Munoz
wrote: Daniel James
writes: Using move emulation caused some problems:
https://svn.boost.org/trac/boost/ticket/6167 https://svn.boost.org/trac/boost/ticket/6311
Yes, but these problems have nothing to do with whether the *elements* of the container are copyable or not, right?
Oh, you've misread the documentation.
Yes, that was my guess also.
Perhaps it is a bit ambiguous. I'll change it to:
* Non-copyable objects can be stored in the containers. * Without support for rvalue references the container will not be movable. * Argument forwarding is not perfect.
This is much clearer, thank you. Regarding the problem described at ticket 6167, I think you can solve it and still have move semantics in pre-C+11 compilers by writing this: // Assign #if defined(BOOST_NO_CXX11_RVALUE_REFERENCES) unordered_set& operator=(unordered_set const& x) { table_.assign(x.table_); return *this; } #endif unordered_set& operator=(BOOST_COPY_ASSIGN_REF(unordered_set) x) { table_.assign(x.table_); return *this; } unordered_set& operator=(BOOST_RV_REF(unordered_set) x) { table_.move_assign(x.table_); return *this; } which is the advice given at http://www.boost.org/doc/libs/1_54_0/doc/html/move/emulation_limitations.htm... (even if a little confusingly) and happens to be more concise than what you currently have. The #ifdef guard is needed because when rvalue refs are supported natively BOOST_COPY_ASSIGN_REF(X) resolves to const X&. Joaquín M López Muñoz Telefónica Digital