Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualZlodo

Posted 07 November 2012 - 03:43 PM

What sicrane said. The idea is that you need to explicitly ask for move semantics to avoid bad surprises. You don't want some function calls to steal your objects through move semantics without explcitly asking for it, which you do using std::move.

If you call a function or assign something and want to move the value instead of copying it, you do something like someFunction( move( thing ) ) or anotherthing = move( thing ). This way you know that thing is not valid anymore after that.

(btw I don't remember what the standard says about the state of an object after it has been moved, iirc it's just up to the move constructor or move operator to make sure the object is in a state where its destructor won't blow up once it goes out of scope)

#1Zlodo

Posted 07 November 2012 - 03:42 PM

What sicrane said. The idea is that you need to explicitly ask for move semantics to avoid bad surprises. You don't want some function calls to steal your objects through move semantics without explcitly asking for it, which you do using std::move.

If you call a function or assign something and want to move the value instead of copying it, you do something like someFunction( move( thing ) ) or anotherthing = move( thing ). This way you know that thing is not valid anymore after that.

(btw I don't remember what the standard says about the state of an object after it has been moved, iirc it's just up to the move constructor or move operator to make sure the object is in a state where the destructor won't blow up once it goes out of scope)

PARTNERS