Hi, Howard Hinnant wrote:
* The move-only class author must know about boost::detail::rv (unique_ptr demonstrates use). The move-only class client needs to know only about boost::move and boost::forward.
Porting Interprocess to this move emulaton I have realized that a move function like template <class T> inline typename enable_if_c < !detail::is_convertible<T, detail::rv<T> >::value, T&
::type move(T& t) { return t; }
is quite problematic for container implementation. With the old emulation (that returned detail::rv<T>) this was possible: class vector { void push_back(const value_type &); void push_back(boost::detail::rv<value_type>); } //copy value_type v; v.push_back(v) //move value_type v; v.push_back(boost::move(v)); but this is not possible with this emulation. Moreover, for emplace functions, they could be implemented like this: template<class T1, class T2, class T3, ...> void emplace_back(const T1 &t1, const T2 &t2, const T3 &t3,....) The "rvalueness" was forwarded with detail::rv with some preprocessor tricks. Sadly, changing the return type from T to boost::detail::rv<value_type> works with Visual 7.1 but not with GCC 4.3: movable function(movable m) { return movable(boost::move(m)); } //this works both with Visual 7.1 and GCC 4.3 movable m; movable m2(boost::move(m); //this only works with visual movable m3(function(boost::move(m2)); With GCC 4.3 (surely more standard conforming that Visual 7.1) boost::detail::rv<> -> T conversion don't work when passing arguments in function calls. To solve this we need to explicitly call: movable m3(function(movable(boost::move(m2))); which is ugly. But not having a way to distinguish a pseudo-rvalue reference and a reference I think causes more harm than good. If we could somehow find a way to avoid writing "function(movable(boost::move(m2))" while maintaning boost::detail::rv<T> as the result of move() that would be perfect. Regards, Ion