A Moving Discussion

• Continuing in chapter 9, you should read it.
• Hopefully we will get to smart pointers.
  • But it not, we need one idea: ownership
  • We have been doing this with our dynamic memory classes
    • Only one instance holds ownership of the dynamic memory.
    • If we "copy it" we do a deep copy to provide new memory that the copied class has ownership of.
  • In c++, move semantics "move" the memory or the ownership from one object to another.
  • This is useful for temporary situations.
• The man pages we will discuss later lists other types of resources we might want to manage in this way
  • file descriptors
  • I/O stream
  • Threads
  • TCP Sockets.
  • And others.
• The basic idea is to provide a shallow copy that the compiler can use when it detects this is appropriate.
• Consider the following code

  • NoisyT CreateNoisy() {
       return NoisyT(3);
    }
    ...
    
    NoisyT a;
    
    a = CreateNoisy(); 

  • a is a full instance of a NoisyT.
  • When the function is called, a temporary variable of type NoisyT is created.
  • But as soon as it is copied to a, it will be destroyed.
  • If this temporary instance has a huge set of dynamic memory, we normally must
    • Delete the dynamic data in a.
    • Allocate a new set of dynamic memory in a
    • Copy the data from the temp instance to a
    • Delete the data in the temp instance
  • But the last three steps are silly.
    • We really just want to move the pointers from the temp instance to a.
    • Or do a shallow copy.
    • Gregorie calls it "copy and swap"
    • The cppreference says that the operators "steal" the resource held by the argument.
  • This is where the overloaded move assignment operator comes in.
  • The move assignment operator.
    • return-type operator = (type && other)
    • The return type type & is favored.
    • NoisyT & operator =(NoisyT && other) noexcept {
  • When the compiler encounters a case where this would be useful, it will call the move = operator, if one exists.
  • This operator should
    • lhs = rhs, or lhs.=(&& rhs)
    • Free any memory in the lhs
    • Does a shallow copy of all the data from the rhs to the lhs.
    • sets the data in the rhs to empty, it no longer owns it.
  • Take a look at moveVsCopy.cpp.
  • The move copy constructor works the same way.
    • NoisyT(NoisyT && other) noexcept {
    • No need to free resources.
    • Just shallow copy of the data
    • Then wipe out the values in the parameter.
  • These can be deleted or defaulted if you wish
    • NoisyT(NoisyT && other) = default
    • NoisyT(NoisyT && other) = delete
  • The rule of 5
    • If you provide any of the five (destructor, copy constructor, move copy constructor, overloaded assignment operator, overloaded move assignment operator), you should provide all of them.
    • Typically if you provide one, the compiler will not provide the others.
    • It is sometimes hard to predict when these will be used by the compiler,
    • But you probably should provide them.
  • By the way, there is also a compiler optimization
    • RVO - Return Value Optimization
    • NRVO - Named Return Value Optimization.
    • See copy elision.
    • They actually can construct the object in the final destination.
    • This can result in fewer calls to constructors/assignment operators.
  • None of these are necessary, but you can achieve a huge performance improvement if you implement them.
  • One last thing, (Based on a question from Cole),
  • The move function
    • move
    • This is from #include <utility>
    • It calls a move operator.
    • This is what is happening in the vector class.
    • And something you might want to do if you have a fairly complex mo ster class.
      • The monsters are on a game board.
      • And they move from one square to nother.
      • Board[newi, newj] = Board[oldi,oldj]
      • Board[newi, newj] = move(Board[oldi,oldj])