[variant] Why no move emulation with Boost.Move for C++03?
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)? Regards, &rzej
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. In Christ, Steven Watanabe
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. WBR, Adam Romanek
2014-04-14 10:16 GMT+04:00 Adam Romanek <romanek.adam@gmail.com>:
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:34 GMT+02:00 Antony Polukhin <antoshkka@gmail.com>:
2014-04-14 10:16 GMT+04:00 Adam Romanek <romanek.adam@gmail.com>:
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.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. HTH, Kris [1] http://boost.2283326.n4.nabble.com/move-interest-the-pass-by-value-and-swap-...
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
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. Best, Ion
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
participants (7)
-
Adam Romanek -
Adam Wulkiewicz -
Andrzej Krzemienski -
Antony Polukhin -
Ion Gaztañaga -
Krzysztof Czainski -
Steven Watanabe