Re: [boost] [move] interest: the pass-by-value and swap idiom, and explicit copy constructors

Subject: Re: [boost] [move] interest: the pass-by-value and swap idiom, and explicit copy constructors
From: John M. Dlugosz (ngnr63q02_at_[hidden])
Date: 2014-02-20 16:37:45

On 2/14/2014 10:52 AM, Krzysztof Czainski wrote:
> (boost::copy()), which compliments the protocol for explicitly stating in
> code, where a move is allowed (std::move() or boost::move());

My recent experience is that the choice of std::move or boost::move depends on the 
destination, not the object itself.  My situation is when Boost is built with move 
emulation but the compiler really does have rvalue references.  If I'm calling something 
that is built with move emulation only (like boost containers) then it is necessary to use 
boost::move around the parameter.  For my own functions which use &&, then std::move (or 
my work-alike in my own namespace, for C++03 std libraries) is required.

I was thinking originally of having my move work-alike figure out if it's a 
move-emulation-enabled type and doing it the boost way, or not and doing it the native 
way.  But I quickly discovered that the same class needs both applied to it in different 
situations!

I'm especially interested in having boost.Move support the situation where it is built 
with NO_RVALUE_REFERENCES but they really are available, but the standard library doesn't 
have std::move, forward, etc.