Copy Control (Part II)Motivation for Move SemanticsSynthesized Move OperationsR-Values, L-Values, and References to EitherMove ConstructorsMove-Assignment OperatorsMove Semantics and InheritanceCSE 332: C++ copy control IICopy Control (Part II)•Review: copy control consists of 5 distinct operations –A copy constructor initializes an object by duplicating the const l-value that was passed to it by reference–A copy-assignment operator (re)sets an object’s value by duplicating the const l-value passed to it by reference–A destructor manages the destruction of an object–A move constructor initializes an object by transferring the implementation from the r-value reference passed to it–A move-assignment operator (re)sets an object’s value by transferring the implementation from the r-value reference passed to it•Today we’ll focus on the last 2 operations and other features (introduced in C++11) like r-value references–I.e., features that support the new C++11 move semanticsCSE 332: C++ copy control IIMotivation for Move Semantics•Copy construction and copy-assignment may be expensive due to time/memory for copying•It would be more efficient to simply “take” the implementation from the passed object, if that’s ok•It’s ok if the passed object won’t be used afterward–E.g., if it was passed by value and so is a temporary object–E.g., if a special r-value reference says it’s ok to take from (as long as object remains in a state that’s safe to destruct)•Note that some objects require move semantics–I.e., types that don’t allow copy construction/assignment–E.g., unique_ptr, ifstream, thread, etc.•New for C++11: r-value references and move function–E.g., int i; int &&rvri = std::move(i);CSE 332: C++ copy control IISynthesized Move Operations•Compiler will only synthesize a move operation if –Class does not declare any copy control operations, and–Every non-static data member of the class can be moved •Members of built-in types can be moved–E.g., by std::move etc.•User-defined types that have synthesized/defined version of the specific move operation can be moved•L-values are always copied, r-values can be moved–If there is no move constructor, r-values only can be copied•Can ask for a move operation to be synthesized–I.e., by using = default –But if cannot move all members, synthesized as = deleteCSE 332: C++ copy control IIR-Values, L-Values, and References to Either•A variable is an l-value (has a location)–E.g., int i = 7; •Can take a regular (l-value) reference to it–E.g., int & lvri = i; •An expression is an r-value–E.g., i * 42 •Can only take an r-value reference to it (note syntax)–E.g., int && rvriexp = i * 42; •Can only get r-value reference to l-value via move–E.g., int && rvri = std::move(i); –Promises that i won’t be used for anything afterward–Also, must be safe to destroy i (could be stack/heap/global)CSE 332: C++ copy control IIMove Constructors•Note r-value reference–Says it’s safe to take a’s implementation from it–Promises only subsequent operation will be destruction•Note constructor design–A lot like shallow copy constructor’s implementation–Except, zeroes out state of a–No sharing, current object owns the implementation–Object a is now safe to destroy (but is not safe to do anything else with afterward)// takes implementation from aIntArray::IntArray(IntArray &&a) : size_(a.size_), values_(a.values_) { // make a safe to destroy a.values_ = nullptr; a.size_ = 0;}CSE 332: C++ copy control IIMove-Assignment Operators•No allocation, so no exceptions to worry about–Simply free existing implementation (delete values_)–Then copy over size and pointer values from a–Then zero out size and pointer in a•This leaves assignment complete, a safe to destroy–Implementation is transferred from a to current objectArray & Array::operator=(Array &&a) { // Note r-value reference if (&a != this) { // still test for self-assignment delete [] values_; // safe to free first (if not self-assigning) size_ = a. size_; // take a’s size value values_ = a.values_; // take a’s pointer value a.size_ = 0; // zero out a’s size a.values_ = nullptr; // zero out a’s pointer (now safe to destroy) } return *this; }CSE 332: C++ copy control IIMove Semantics and Inheritance•Base classes should declare/define move operations–If it makes sense to do so at all–Derived classes then can focus on moving their members–E.g., calling Base::operator= from Derived:: version•Containers further complicate these issues–Containers hold their elements by value–Risks slicing, other inheritance and copy control problems•So, put (smart) pointers, not objects, into containers–Access is polymorphic if destructors, other methods virtual–Smart pointers may help reduce need for copy control operations, or at least simplify cases where