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?
Option<vector<int>> 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 <[email protected]> wrote:
> +1 for 1. “treat it like a deleted pointer”
>
>
> > On Jun 12, 2015, at 4:21 PM, Alexander Rojas <[email protected]>
> 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::vector<int> 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::vector<int> 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::vector<int> v{1, 2, 3};
> > ….
> > foo(std::move(v));
> > }
> >
>
>
