Re: [boost] [move] BOOST_RV_REF(TypeWithoutMoveEmulation) parameters

Subject: Re: [boost] [move] BOOST_RV_REF(TypeWithoutMoveEmulation) parameters
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-05-22 01:21:20

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.