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

Subject: Re: [boost] [variant] Basic rvalue and C++11 features support
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-11-02 11:10:16

Le 02/11/12 08:36, Antony Polukhin a écrit :
> 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.
>
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