Le 02/11/12 08:36, Antony Polukhin a écrit :
2012/11/2 paul Fultz <pfultz2@yahoo.com>:
From: Dave Abrahams <dave@boostpro.com>
Hi,
I have not analyzed completely the patch but I see that Boost.Move is not used to emulate move semantics on C++98. Is there a deep reason to don't use it? +1 See https://svn.boost.org/trac/boost/ticket/7601 ... But if it were to use Boost.Move, this will no longer compile, breaking barkwards compatibility. Yes, main reason for not using Boost.Move's macrosses is compatibility. To be honest, I did not know about the issue mentioned by Paul Fultz. I was just scared with a huge amount of workarounds for compilers with broken constructor template orderings and MSVC6 specific hacks. Using some of the Boost.Move macrosses would definitely break compilation on some old/buggy compilers.
Compilers that do support rvalues have no such bugs (or at least all of thouse compilers are being tested in regression tests), so allowing move optimizations only for C++11 compilers seemed reasonable.
About ticket #7601. Using ONLY boost::move function (and NO macrosses) can give some performance gains without risk to break compatibility for C++03 compilers. For example, after applying patch #7620 there are some places which could benefit if users type uses Boost.Move (for example `move_into` visitor has code like T(::boost::detail::variant::move(operand))). I did not used Boost.Move in #7620 for simplicity of debugging: I did not wanted to mix possible bugs of #7620 patch with possible bugs of #7601.
Hi, I have some experience making portable move semantics for Boost.Thread which has also its own bugged move semantics emulation. I've added my own macros that use either the Boost.Move macros or the equivalent for the legacy emulation. This is a transitory step as IMO the legacy should be deprecated soon. While I agree that the use of macros is not ideal, don't have a correct c++03 implementation that is close to the C++11 one is a shame. However making a portable implementation is sometimes a headache, as there is not a C++03 move semantic emulation for general purpose classes as tuple, bind, shared_ptr, ... and other TR1. I really think that it is worth the effort and I hope that the Boost community will finish by providing a C++portable move semantic emulation if we don't want that the libraries finish as is the case of Boost.Variant, Boost.Fusion, ... providing only C++11 move semantics. Best, Vicente