2014-04-14 10:16 GMT+04:00 Adam Romanek :

On 04/13/2014 02:59 PM, Steven Watanabe wrote:

...

Boost.Move is not completely backwards compatible. i.e. adding it to an existing class can break user code.

Steven, could you please elaborate on this? I mean how can it break existing code? And what about backward compatibility? I haven't found anything on it in the documentation. Thanks in advance.

Main restriction that affect portability is described here: http://www.boost.org/doc/libs/1_55_0/doc/html/move/emulation_limitations.html#move.emulation_limitations.assignment_operator("Assignment operator in classes derived from or holding copyable and movable types") It is a big problem. For example this limitation broke compilation of Boost.ProgramOptions after move emulation was added to Boost.Any: http://boost.2283326.n4.nabble.com/any-last-commit-breaks-program-options-td... Because of that restriction Boost.Variant, Boost.Any and Boost.CircularBuffer do not use Boost.Move emulation everywhere. For those libraries some of the move functions are available only in C++11 mode. -- Best regards, Antony Polukhin

2014-04-14 10:53 GMT+02:00 Krzysztof Czainski <1czajnik@gmail.com>:

Main restriction that affect portability is described here:

...

http://www.boost.org/doc/libs/1_55_0/doc/html/move/emulation_limitations.htm... "Assignment operator in classes derived from or holding copyable and movable types")

It is a big problem. For example this limitation broke compilation of Boost.ProgramOptions after move emulation was added to Boost.Any:

http://boost.2283326.n4.nabble.com/any-last-commit-breaks-program-options-td...

Because of that restriction Boost.Variant, Boost.Any and Boost.CircularBuffer do not use Boost.Move emulation everywhere. For those libraries some of the move functions are available only in C++11 mode.

I think with an assignment operator implemented in terms of the pass-by-value and swap idiom, you get a CopyAssignamble as well as a MoveAssignable type without this issue. I described this here [1] together with my 'explicit copy' proposition.

I don't think this approach is acceptable for in-place containers like optional or variant, where the swap operation isn't just a simple pointer swap. Regards, Kris

Hi, Ion Gaztañaga wrote:

El 13/04/2014 14:59, Steven Watanabe escribió:

...

AMDG

On 04/12/2014 02:33 PM, Andrzej Krzemienski wrote:

...

Hi, I am trying to figure out what the best way to enable move semantics in Boost.Optional. I tried to pick at how Boost.Variant does it. If I understand correctly, move operations are only defined if compiler supports rvalue references. I wonder why it doesn't use Boost.Move, which would enable move semantics even for compilers w/o rvalue references. Is there any reason for this (that I should also take into account for Boost.Optional)?

Boost.Move is not completely backwards compatible. i.e. adding it to an existing class can break user code.

If the assignment operator is a major problem, we can define another alternative that can be less efficient in some contexts but maintain assignment operator intact.

With a "standard" copy assignment? Btw, I proposed to do this for Tuples some time ago - https://svn.boost.org/trac/boost/ticket/7276. Regards, Adam