Re: Style guide for std::move
Also, do we want to allow a re-assignment after a move to re-use the object?
Just some food for thought, have you explored extending Option to capture
this?
Optionvectorint v {1, 2, 3, 4};
foo(v.move());
v.isSome(); // false
v = {1, 2, 3, 4};
v.isSome() // true
On Wed, Jun 17, 2015 at 7:19 AM, Till Toenshoff toensh...@me.com wrote:
+1 for 1. “treat it like a deleted pointer”
On Jun 12, 2015, at 4:21 PM, Alexander Rojas alexan...@mesosphere.io
wrote:
Hey guys, there have been questions on how to deal with std::move in the
code. Right now our style guide says nothing about it, but there is no
consensus in the reviews. The problem with std::move is that for all
standard library functions that accept rvalue references as parameters are
guaranteed to leave the moved object in a valid but unspecified state (see
http://en.cppreference.com/w/cpp/utility/move
http://en.cppreference.com/w/cpp/utility/move).
The following are some ideas into how to deal with moved objects
1. Treat std::move as a delete and stop using it after the move
std::vectorint v{1, 2, 3, 4};
..,
foo(std::move(v)); // Don’t use
2. Always create explicitly an scope the object to be moved, with the
first line being the definition of the object to be moved, and the last
line of the scope the move itself.
if (bar()) {
{
std::vectorint v{1, 2, 3};
….
foo(std::move(v));
}
}
3. Create a scope for the if no scope already exists following the rules
of 2):
if (bar()) {
std::vectorint v{1, 2, 3};
….
foo(std::move(v));
}
Re: Style guide for std::move
+1 for 1. “treat it like a deleted pointer”
On Jun 12, 2015, at 4:21 PM, Alexander Rojas alexan...@mesosphere.io wrote:
Hey guys, there have been questions on how to deal with std::move in the
code. Right now our style guide says nothing about it, but there is no
consensus in the reviews. The problem with std::move is that for all standard
library functions that accept rvalue references as parameters are guaranteed
to leave the moved object in a valid but unspecified state (see
http://en.cppreference.com/w/cpp/utility/move
http://en.cppreference.com/w/cpp/utility/move).
The following are some ideas into how to deal with moved objects
1. Treat std::move as a delete and stop using it after the move
std::vectorint v{1, 2, 3, 4};
..,
foo(std::move(v)); // Don’t use
2. Always create explicitly an scope the object to be moved, with the first
line being the definition of the object to be moved, and the last line of the
scope the move itself.
if (bar()) {
{
std::vectorint v{1, 2, 3};
….
foo(std::move(v));
}
}
3. Create a scope for the if no scope already exists following the rules of
2):
if (bar()) {
std::vectorint v{1, 2, 3};
….
foo(std::move(v));
}
Style guide for std::move
Hey guys, there have been questions on how to deal with std::move in the code.
Right now our style guide says nothing about it, but there is no consensus in
the reviews. The problem with std::move is that for all standard library
functions that accept rvalue references as parameters are guaranteed to leave
the moved object in a valid but unspecified state (see
http://en.cppreference.com/w/cpp/utility/move
http://en.cppreference.com/w/cpp/utility/move).
The following are some ideas into how to deal with moved objects
1. Treat std::move as a delete and stop using it after the move
std::vectorint v{1, 2, 3, 4};
..,
foo(std::move(v)); // Don’t use
2. Always create explicitly an scope the object to be moved, with the first
line being the definition of the object to be moved, and the last line of the
scope the move itself.
if (bar()) {
{
std::vectorint v{1, 2, 3};
….
foo(std::move(v));
}
}
3. Create a scope for the if no scope already exists following the rules of 2):
if (bar()) {
std::vectorint v{1, 2, 3};
….
foo(std::move(v));
}
