On 20/05/2017 02:16, Groke, Paul wrote:
I'd like to use BOOST_RV_REF, with both C++98 and C++11 compilers, for some sink-functions, with types that are not "move-enabled". I.e. types that the sink can "consume"/"move from" by other means (swapping, calling .release(), ...). Some of them I can - eventually - change to be fully move-enabled, others I can not (e.g. STL classes).
I just assumed that this was possible by simply passing the argument with boost::move(arg). Apparently it's not though, because boost::move will return a plain T& for types without move emulation. For the time being I have defined my own helper function template "move_any" that will always return a rv<T>&.
Is there such a function that I missed? And if not, would you think it'd make sense to provide one (I certainly think it would)?
Apologies for the prior blank reply; accidentally fat-fingered the Send button. I don't think this makes sense. The Boost.Move emulation library is exactly that -- an as-close-to-possible *emulation* of rvalue-reference-based C++11 move for pre-C++11 compilers. As such it is naturally designed for modification of the type-to-be-moved (it requires adding move constructors etc as applicable). Additionally, when actually compiled in C++11 it gracefully upgrades to actual rvalue references -- as such the rv<T> class disappears entirely; this is an implementation detail and you're not supposed to use it outside of the macros in the documented interface of Boost.Move. (Also, I have grave doubts that returning one by reference could be correct code, as they're typically locally constructed IIRC.) If you want to write some generic code around swap(), then do that; this exists for both C++11 and prior. Also, be careful with move. It's a shiny new toy so people are excited to play with it, but if not used carefully (*especially* with a non-C++11 STL) it can easily lead to incorrect behaviour or degraded performance. Learn both when and when *not* to use it.