Daniel James writes:

On 8 July 2013 09:17, Joaquin M Lopez Munoz wrote:

...

Here:

http://www.boost.org/doc/html/unordered/compliance.html#unordered.compliance...

...

it reads:

"Non-copyable objects can be stored in the containers, but without support for rvalue references the container will not be movable."

Why not? Container movement does not ever touch its elements, so I don't see the connection.

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? Joaquín M López Muñoz Telefónica Digital

Daniel James writes:

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