On Tue, Feb 11, 2014 at 9:14 AM, Krzysztof Czainski <1czajnik@gmail.com> wrote:
2014-02-11 14:11 GMT+01:00 Ion Gaztaņaga <igaztanaga@gmail.com>:
El 11/02/2014 8:55, Adam Romanek escribiķ:

Hi!

Some time ago I encountered a problem with assigning the return value of
boost::move() to a non-const reference in C++11 mode, but not in C++03
mode. See [1] for a StackOverflow question that I created for this
issue. It contains all the details so for brevity I won't repeat them
here. Could anyone explain this issue? Is this a limitation of C++03
emulation or a defect in the implementation?

Yes, it's a limitation of boost move. When called with the emulation code boost::move() returns a type rv<T> & that is convertible to T (and that is the key point to implement emulated move semantics). However in C++11 you return a T&& (unnamed rvalue reference) which is not assignable to T &.

In your case, as R is std::ostream &, the emulation return rv<std::ostrean> (convertible to std::ostream &) and the C++11 version returns std::ostream &&, which is not convertible to std::ostream &.

I guess we could add a new macro to boost move for return types. In emulated mode, it moves the return value, In C++11 mode it only return the value (If RVO can't be applied the compiler will do an implicit move). Something like:

//return boost::move(r) in emulation
//return r in C++11
return BOOST_MOVE_RET(r);
+1
I've written and use such a macro myself.
Regards,
Kris 

_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

I recently wanted to write such a macro too. Objects marked with BOOST_MOVABLE_BUT_NOT_COPYABLE have to be returned with "return boost::move(temp)" or C++03 compilers try to use the private copy-constructor on temp. Doing a boost::move return prevents NRVO in C++03, and C++11 (according to the language purists and gcc 4.7.3). This macro would at least provide NRVO capabilities in C++11. I think C++03 support for NRVO in this situation is foolish; boost::move would have to invoke a private copy-constructor on the user type and hope the compiler didn't generate a function call to it. The documentation doesn't list these limitations AFAIK.

Lee