Re: [boost] [variant] Basic rvalue and C++11 features support

Subject: Re: [boost] [variant] Basic rvalue and C++11 features support
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2012-11-02 03:36:26

2012/11/2 paul Fultz <pfultz2_at_[hidden]>:
>> From: Dave Abrahams <dave_at_[hidden]>
>>>  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.

--
Best regards,
Antony Polukhin