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?
...
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. -- Best regards, Antony Polukhin