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.