{"title":"Move Constructor","description":null,"content":"A move constructor builds a new object by stealing the resources of an existing one, instead of making a copy. It exists so that objects which own expensive resources (heap memory, file handles, network connections) can be transferred efficiently between functions and containers. This lesson covers what move semantics solve, the rvalue reference syntax `&&`, the move constructor signature, what \"valid but unspecified state\" means, when the compiler generates one for you, and how `std::move` participates in all of this.\n\n---\n\n# The Problem: Deep Copies Are Expensive\n\nSome objects own resources. A `std::vector` holds a pointer to a heap-allocated array. A `std::string` holds a pointer to a heap-allocated character buffer. A custom class might hold a raw `new`-allocated buffer or a file handle. Whatever the resource, copying the object means duplicating the resource.\n\nConsider a `Cart` class that owns a heap buffer of prices:\n\n\n```cpp\n#include \n#include \n\nclass Cart {\npublic:\n int size;\n double* prices;\n\n Cart(int n) : size(n), prices(new double[n]) {\n for (int i = 0; i < n; i++) {\n prices[i] = 0.0;\n }\n std::cout << \"constructed cart of size \" << size << \"\\n\";\n }\n\n // copy constructor: deep copy\n Cart(const Cart& other) : size(other.size), prices(new double[other.size]) {\n std::memcpy(prices, other.prices, size * sizeof(double));\n std::cout << \"copied cart of size \" << size << \"\\n\";\n }\n\n ~Cart() {\n delete[] prices;\n std::cout << \"destroyed cart of size \" << size << \"\\n\";\n }\n};\n\nCart makeCart(int n) {\n Cart local(n);\n for (int i = 0; i < n; i++) {\n local.prices[i] = (i + 1) * 9.99;\n }\n return local;\n}\n\nint main() {\n Cart c = makeCart(1'000'000);\n std::cout << \"first price: \" << c.prices[0] << \"\\n\";\n return 0;\n}\n```\n\n\nWithout move semantics, returning `local` from `makeCart` would build a copy of a one-million-element heap array, then destroy the original. Two million doubles allocated, copied, and freed, to hand back one. The copy constructor is correct, but it does eight megabytes of work that the caller does not need.\n\nWhen an object is about to be destroyed anyway (like the local at the return point), the program doesn't need to copy its contents. It can transfer ownership of the heap pointer to the destination, leave the original pointing at nothing, and skip the allocation and copy entirely. That transfer is what a move constructor does.\n\n---\n\n# rvalue References: The `&&` Type\n\nC++11 introduced a new kind of reference written with two ampersands: `T&&`. This is an **rvalue reference**. To understand why it exists, you have to understand the lvalue/rvalue distinction.\n\nEvery expression in C++ is either an **lvalue** or an **rvalue**:\n\n- An **lvalue** has a name and a stable identity. You can take its address. A variable like `cart` is an lvalue.\n- An **rvalue** is a temporary or a value about to expire. The result of `makeCart(5)`, the literal `42`, the expression `a + b`, all rvalues. They don't have a stable identity, and the program will throw them away shortly.\n\nA plain reference `T&` (an **lvalue reference**) binds only to lvalues. You can't bind it to a temporary:\n\n\n```cpp\nCart& bad = makeCart(5); // error: cannot bind lvalue ref to rvalue\n```\n\n\nA `const T&` is more flexible: it binds to both, which is why `const T&` parameters are everywhere in C++. But `const` rules out modifying the object.\n\nAn rvalue reference `T&&` binds **only to rvalues**:\n\n\n```cpp\nCart&& temp = makeCart(5); // ok: rvalue ref binds to a temporary\n```\n\n\n`T&&` gives code a way to say \"I want to handle a value that's about to be destroyed, and I want to be allowed to modify it.\" The \"modify\" part is what enables stealing its resources.\n\n\n| Reference Type | Binds to lvalues? | Binds to rvalues? | Can modify? |\n|----------------|-------------------|-------------------|-------------|\n| `T&` | Yes | No | Yes |\n| `const T&` | Yes | Yes | No |\n| `T&&` | No | Yes | Yes |\n\n\nThe rvalue reference is the type the compiler uses to find a move constructor when one is available, falling back to the copy constructor (which takes `const T&`) when it isn't.\n\n**Quick Check:** Which of these compiles?\n\n\n```cpp\nint makeFive() { return 5; }\nint x = 10;\n\nint& a = makeFive(); // (A)\nconst int& b = makeFive(); // (B)\nint&& c = makeFive(); // (C)\nint&& d = x; // (D)\n```\n\n\n- A) A only\n- B) B and C\n- C) B, C, and D\n\n

Answer

\n\n**B.** `B` works because `const int&` binds to temporaries. `C` works because `int&&` binds to rvalues. `A` fails because a plain `int&` cannot bind to a temporary. `D` fails because `x` is an lvalue and `int&&` rejects lvalues.\n\n

\n\n---\n\n# The Move Constructor Signature\n\nA move constructor is a constructor whose parameter is an rvalue reference to its own class:\n\n\n```cpp\nClassName(ClassName&& other) noexcept;\n```\n\n\nThree parts of that signature matter:\n\n- **`ClassName&&`**: the rvalue reference parameter. This is what makes it a move constructor instead of a copy constructor.\n- **`other`**: the parameter name. By convention, the parameter is `other` or `rhs` (right-hand side).\n- **`noexcept`**: a promise that the move will not throw. Standard library containers like `std::vector` only use the move constructor (instead of copying) when it is marked `noexcept`. Without `noexcept`, a vector that needs to grow will copy elements one by one instead of moving them, which defeats the purpose.\n\nA move constructor for the `Cart` class:\n\n\n```cpp\n#include \n#include \n#include \n\nclass Cart {\npublic:\n int size;\n double* prices;\n\n Cart(int n) : size(n), prices(new double[n]) {\n for (int i = 0; i < n; i++) prices[i] = 0.0;\n }\n\n // copy constructor: deep copy\n Cart(const Cart& other) : size(other.size), prices(new double[other.size]) {\n std::memcpy(prices, other.prices, size * sizeof(double));\n std::cout << \"copy ctor\\n\";\n }\n\n // move constructor: steal the buffer\n Cart(Cart&& other) noexcept : size(other.size), prices(other.prices) {\n other.size = 0;\n other.prices = nullptr;\n std::cout << \"move ctor\\n\";\n }\n\n ~Cart() {\n delete[] prices;\n }\n};\n\nCart makeCart(int n) {\n Cart local(n);\n local.prices[0] = 19.99;\n return local; // candidate for move\n}\n\nint main() {\n Cart c = makeCart(1'000'000);\n std::cout << \"first price: \" << c.prices[0] << \"\\n\";\n return 0;\n}\n```\n\n\n**Sample Output:**\n\n\n```shell\nfirst price: 19.99\n```\n\n\nNo \"copy ctor\" line is printed. With modern compilers, the return value optimization may eliminate even the move (constructing `local` directly into `c`'s memory), but if the move did happen, no million-element copy would. The move constructor simply takes ownership of `other.prices`, then resets `other` to a safe empty state.\n\n---\n\n# Transferring Ownership\n\nInside a move constructor, the work splits into two parts. First, copy the small handles (the pointer, the size, any other lightweight tracking fields) from the source. Second, leave the source in a state where its destructor will not free the resources you just stole.\n\n\n```mermaid\nflowchart LR\n subgraph BEFORE[Before move]\n S1[source.size = 1000
source.prices --> heap]:::cyan\n H1[heap buffer
1000 doubles]:::orange\n S1 --> H1\n end\n\n subgraph AFTER[After move]\n S2[source.size = 0
source.prices = nullptr]:::red\n D2[dest.size = 1000
dest.prices --> heap]:::green\n H2[same heap buffer
1000 doubles]:::orange\n S2 -.-> X[ ]\n D2 --> H2\n end\n\n BEFORE --> AFTER\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe heap buffer doesn't move. Only the pointer changes hands. The source's pointer is reset to `nullptr`, so when the source is destroyed, `delete[] nullptr;` runs (which is a safe no-op) instead of freeing the buffer that now belongs to the destination.\n\nMove semantics comes down to pointer reassignment with no deep copy.\n\nIf you forget the reset step, both objects hold the same pointer, and the buffer gets freed twice when both objects go out of scope. That is a double-free, and the program will crash or corrupt the heap.\n\n**What is wrong with this move constructor?**\n\n\n```cpp\nCart(Cart&& other) noexcept : size(other.size), prices(other.prices) {\n // forgot to clear other.prices\n}\n```\n\n\nBoth `other` and the new object now hold the same pointer. When `other` is destroyed, its destructor calls `delete[] prices;`. When the new object is destroyed later, its destructor calls `delete[]` on the same address. Double-free, undefined behavior.\n\n**Fix:** always reset the source's owning fields to a safe value.\n\n\n```cpp\nCart(Cart&& other) noexcept : size(other.size), prices(other.prices) {\n other.size = 0;\n other.prices = nullptr;\n}\n```\n\n\n---\n\n# The \"Valid but Unspecified\" State\n\nAfter a move, the moved-from object is still alive. It will eventually be destroyed (or assigned to), so its destructor needs to do something sensible. The C++ standard says a moved-from object must be in a **valid but unspecified state**.\n\n\"Valid\" means:\n\n- Its destructor can run safely.\n- You can assign to it.\n- You can call any function that has no precondition (like a method that doesn't assume the object holds data).\n\n\"Unspecified\" means:\n\n- You shouldn't read its values expecting any particular content.\n- Methods with preconditions (like \"the cart must be non-empty\") might not be safe to call.\n\nFor the `Cart` example, after `Cart moved = std::move(original);`, the moved-from `original` has `size = 0` and `prices = nullptr`. The destructor runs fine on that state. If somebody calls `original.prices[0]` afterward, that's their bug, not the move's.\n\nStandard library types follow this rule. After moving from a `std::string`, the source might be empty or might still hold its old characters; you don't know. After moving from a `std::vector`, the source is typically (but not required to be) empty. The safe rule: don't read from a moved-from object. Assign a new value to it, or let it go out of scope.\n\n**Quick Check:** What does this print?\n\n\n```cpp\n#include \n#include \n#include \n\nint main() {\n std::string a = \"Wireless Mouse\";\n std::string b = std::move(a);\n std::cout << \"b: \" << b << \"\\n\";\n std::cout << \"a length: \" << a.length() << \"\\n\"; // ???\n return 0;\n}\n```\n\n\n- A) Always prints `a length: 14`\n- B) Always prints `a length: 0`\n- C) Prints `b: Wireless Mouse`, and `a length:` could be anything\n\n

Answer

\n\n**C.** `b` is guaranteed to hold `\"Wireless Mouse\"` after the move. `a` is in a valid but unspecified state. Most implementations leave it empty, but the standard does not require this. Reading `a` is legal (no UB), but you cannot depend on its contents.\n\n

\n\n---\n\n# `std::move`: Casting to an rvalue\n\nA named variable is always an lvalue, even if it was declared as `T&& x`. The rule is deliberate: once you can refer to something by name, it's stable enough to be an lvalue, and binding lvalues to rvalue references would be unsafe.\n\nSo this doesn't call the move constructor:\n\n\n```cpp\nCart a(100);\nCart b = a; // calls COPY constructor; a is an lvalue\n```\n\n\nTo move from `a`, the compiler needs an explicit signal to treat `a` as an rvalue, even though it has a name. `std::move` provides that signal. It is a cast to an rvalue reference. Despite the name, it does not move anything by itself; it only changes the type so the compiler will select the move constructor at the next step.\n\n\n```cpp\n#include // for std::move\n\nCart a(100);\nCart b = std::move(a); // calls MOVE constructor\n```\n\n\nAfter this line, `a` is in its moved-from state, and `b` holds the buffer that `a` used to own.\n\n\n```mermaid\nflowchart LR\n A[a: lvalue
has a name]:::cyan\n M[std::move(a)]:::orange\n R[expression treated
as rvalue]:::green\n CT[move constructor
chosen by overload
resolution]:::teal\n\n A --> M --> R --> CT\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\n`std::move` is equivalent to `static_cast(x)`. It is a zero-cost compile-time operation. The actual work happens in the move constructor that gets called as a result.\n\nA common use is to push existing objects into a container without copying:\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nint main() {\n std::vector products;\n std::string name = \"Wireless Mouse\";\n\n products.push_back(name); // copies \"Wireless Mouse\"\n products.push_back(std::move(name)); // moves; name is now empty (typically)\n\n std::cout << \"products[0]: \" << products[0] << \"\\n\";\n std::cout << \"products[1]: \" << products[1] << \"\\n\";\n std::cout << \"name length: \" << name.length() << \"\\n\";\n return 0;\n}\n```\n\n\n**Sample Output (libstdc++):**\n\n\n```shell\nproducts[0]: Wireless Mouse\nproducts[1]: Wireless Mouse\nname length: 0\n```\n\n\nThe two `push_back` calls insert the same string, but the first copies it (so the original `name` is untouched) while the second moves it (so the original `name` is left empty on most implementations).\n\nWhen `std::move` is the wrong choice, the worst case is that you slow yourself down by accidentally suppressing a copy elision optimization. It's not unsafe, but using it on a local variable that's about to be returned is unnecessary and sometimes counterproductive:\n\n\n```cpp\nCart makeCart() {\n Cart local(100);\n return std::move(local); // unnecessary; prevents NRVO\n}\n```\n\n\nThe compiler would have done a better job on `return local;` because that allows return value optimization to skip the move entirely. Use `std::move` when you mean it, not as a habit.\n\n---\n\n# When the Compiler Generates a Move Constructor\n\nThe compiler generates a default move constructor for your class only under specific conditions. The rules connect to the **Rule of Three / Five / Zero**, which is a heuristic about when you need to write your own special member functions.\n\n**Rule of Three (pre-C++11):** If a class needs a custom destructor, copy constructor, or copy assignment operator, it almost certainly needs all three.\n\n**Rule of Five (C++11+):** Add the move constructor and move assignment operator to the list. If you need any of the five, you probably need all of them.\n\n**Rule of Zero (modern C++):** Design your class so it owns no raw resources directly. Use `std::vector`, `std::string`, `std::unique_ptr`, etc., as members. Then you don't need to write any of the five, and the compiler-generated versions work correctly.\n\nThe compiler **will** generate a move constructor if all of these hold:\n\n1. You did not declare your own move constructor.\n2. You did not declare your own copy constructor, copy assignment operator, move assignment operator, or destructor.\n3. Every non-static data member and base class is itself movable.\n\nThe moment you declare any of those special members yourself, the compiler stops generating the move constructor (and sometimes the move assignment operator). Consider a class like this:\n\n\n```cpp\nclass CartHistory {\npublic:\n std::vector carts;\n\n ~CartHistory() {\n std::cout << \"history destroyed\\n\";\n }\n};\n```\n\n\nBecause `~CartHistory()` is declared explicitly, no move constructor or move assignment operator is generated. Moving a `CartHistory` falls back to the copy constructor with no warning. For a class wrapping a big vector, that's an expensive bug.\n\nThe fix is either to remove the unnecessary destructor (the vector already handles its own cleanup), or to explicitly default the move operations:\n\n\n```cpp\nclass CartHistory {\npublic:\n std::vector carts;\n\n ~CartHistory() {\n std::cout << \"history destroyed\\n\";\n }\n\n CartHistory() = default;\n CartHistory(CartHistory&&) noexcept = default;\n CartHistory& operator=(CartHistory&&) noexcept = default;\n CartHistory(const CartHistory&) = default;\n CartHistory& operator=(const CartHistory&) = default;\n};\n```\n\n\nThis is the verbose way. The cleaner approach is to follow the Rule of Zero: don't write a destructor unless the class owns a raw resource, and the compiler will handle moves correctly on its own.\n\n\n| Rule | When it applies | What to write |\n|------|----------------|---------------|\n| Rule of Zero | Class owns no raw resources | Nothing. Let the compiler generate all five. |\n| Rule of Three | Pre-C++11 class with raw ownership | Destructor, copy ctor, copy assign |\n| Rule of Five | Modern class with raw ownership | All five: destructor, copy ctor, copy assign, move ctor, move assign |\n\n\n**Quick Check:** Will the compiler generate a move constructor for this class?\n\n\n```cpp\nclass Order {\npublic:\n int orderId;\n std::string customer;\n std::vector prices;\n\n ~Order() {}\n};\n```\n\n\n- A) Yes, automatically\n- B) No, because the destructor is user-declared\n- C) No, because `std::string` is not movable\n\n

Answer

\n\n**B.** The user-declared destructor (even an empty one) suppresses the implicit move constructor and move assignment operator. To get them back, either remove the empty destructor or write `Order(Order&&) noexcept = default;` explicitly. `std::string` and `std::vector` are both movable, so the underlying machinery would work fine.\n\n

\n\n---\n\n# A Complete Example: Cart with Move and Copy\n\nA full class showing the move and copy constructors side by side, plus a small program demonstrating which one runs in different situations:\n\n\n```cpp\n#include \n#include \n#include \n\nclass Cart {\npublic:\n int size;\n double* prices;\n\n Cart(int n) : size(n), prices(new double[n]) {\n for (int i = 0; i < n; i++) prices[i] = 0.0;\n std::cout << \"ctor(\" << size << \")\\n\";\n }\n\n // copy: allocate a new buffer and duplicate every price\n Cart(const Cart& other) : size(other.size), prices(new double[other.size]) {\n std::memcpy(prices, other.prices, size * sizeof(double));\n std::cout << \"copy(\" << size << \")\\n\";\n }\n\n // move: take other's pointer, leave other empty\n Cart(Cart&& other) noexcept : size(other.size), prices(other.prices) {\n other.size = 0;\n other.prices = nullptr;\n std::cout << \"move(\" << size << \")\\n\";\n }\n\n ~Cart() {\n std::cout << \"dtor(\" << size << \")\\n\";\n delete[] prices;\n }\n};\n\nint main() {\n Cart a(3); // ctor(3)\n a.prices[0] = 9.99;\n\n Cart b = a; // copy(3) lvalue source\n Cart c = std::move(a); // move(3) a is moved-from\n Cart d(c); // copy(3) d copies from c\n\n return 0;\n}\n```\n\n\n**Sample Output:**\n\n\n```shell\nctor(3)\ncopy(3)\nmove(3)\ncopy(3)\ndtor(3)\ndtor(3)\ndtor(0)\ndtor(3)\n```\n\n\n`a`'s line is `dtor(0)` because `a` was moved-from: its `size` is now `0` and its `prices` is `nullptr`. The other three destructors run on intact carts of size 3. Each one calls `delete[]` on a valid heap pointer, and no double-free occurs because only one `Cart` ever owns each buffer at any time.\n\nThe cost saving becomes clear when `n` is a million instead of three. The `copy` lines each do a million-double `memcpy` plus a million-double heap allocation. The `move` line does none of that. It is the same work as moving a single pointer plus updating two integers.\n\n---\n\n# Interview Questions\n\n**Q1: What problem do move semantics solve?**\n\nCopying an object that owns a heap resource (like a `std::vector` or `std::string`) requires duplicating the resource, which is expensive for large objects. Move semantics let a destination object take ownership of the source's resource handle (typically a pointer), leaving the source in a valid but unspecified state. This turns an O(n) copy into an O(1) pointer reassignment. The savings show up everywhere standard library containers grow, shrink, or get returned from functions.\n\n**Q2: Why is the move constructor's parameter `T&&` instead of `const T&` or `T&`?**\n\n`T&&` (rvalue reference) is a type that binds only to rvalues, which are temporaries and values about to expire. The move constructor needs to modify the source (to reset its pointer to `nullptr`, for example), so the parameter cannot be `const`. It also shouldn't bind to lvalues by default, since stealing a named variable's resources without an explicit cast would surprise the caller. The `&&` overload is what overload resolution picks when the argument is an rvalue and a move constructor is available; lvalues route to the copy constructor instead.\n\n**Q3: Why mark the move constructor `noexcept`, and what happens if you don't?**\n\n`noexcept` promises the move will not throw an exception. Standard library containers like `std::vector` check this promise: if the move constructor is `noexcept`, they use it during reallocation (e.g., when the vector grows). If it might throw, they fall back to copying for safety, because a half-completed move could leave the container in an inconsistent state. Without `noexcept` on the move constructor, you lose the performance benefit in exactly the situations where it matters most.\n\n**Q4: What does `std::move` do?**\n\n`std::move` does no moving by itself. It's a cast that turns an lvalue expression into an rvalue reference, equivalent to `static_cast(x)`. The actual move happens when the resulting rvalue is passed to a constructor or assignment operator that takes `T&&`, which the compiler then selects via overload resolution. Calling `std::move` on a value that isn't about to be discarded leaves it in a moved-from state, which is legal but means you shouldn't read from it afterward.\n\n**Q5: When does the compiler generate a move constructor automatically, and when does it stop?**\n\nThe compiler generates an implicit move constructor only if the class declares none of the other special members: copy constructor, copy assignment operator, move assignment operator, or destructor. The moment you declare any one of those, the implicit move constructor (and usually move assignment too) is suppressed. This is the Rule of Five. A class with an explicit destructor (for example, one that logs) loses its move operations without any warning from the compiler. The fix is either to declare all five with `= default` or, better, to follow the Rule of Zero and use members like `std::vector` or `std::unique_ptr` that already handle move semantics correctly.\n\n---\n\n# Exercises\n\n**Exercise 1:** Write a class `Buffer` that owns a heap-allocated `int*` and an `int size`. Implement a constructor that takes a size, a destructor that releases the memory, and a move constructor that transfers ownership. Print a message in each of the three so you can see when they run.\n\n**Expected Output (sample):**\n\n\n```shell\nctor(5)\nmove(5)\ndtor(5)\ndtor(0)\n```\n\n\n

Solution

\n\n\n```cpp\n#include \n#include \n\nclass Buffer {\npublic:\n int* data;\n int size;\n\n Buffer(int n) : data(new int[n]), size(n) {\n std::cout << \"ctor(\" << size << \")\\n\";\n }\n\n Buffer(Buffer&& other) noexcept : data(other.data), size(other.size) {\n other.data = nullptr;\n other.size = 0;\n std::cout << \"move(\" << size << \")\\n\";\n }\n\n ~Buffer() {\n std::cout << \"dtor(\" << size << \")\\n\";\n delete[] data;\n }\n};\n\nint main() {\n Buffer a(5);\n Buffer b = std::move(a);\n return 0;\n}\n```\n\n\n

\n\n**Exercise 2:** What does this program print? Why?\n\n\n```cpp\n#include \n#include \n#include \n\nint main() {\n std::string a = \"Order #123\";\n std::string b = a;\n std::string c = std::move(a);\n std::cout << \"b: \" << b << \"\\n\";\n std::cout << \"c: \" << c << \"\\n\";\n return 0;\n}\n```\n\n\n**Expected Output:**\n\n\n```shell\nb: Order #123\nc: Order #123\n```\n\n\n

Solution

\n\n`b` is built by the copy constructor, which duplicates `a`'s buffer. `c` is built by the move constructor, which takes ownership of `a`'s buffer. Both end up holding the same string content, but `b` has its own allocation while `c` reused `a`'s. Reading `a` after the move would be legal but produce an unspecified value.\n\n

\n\n**Exercise 3:** Fix the move constructor in this class so it doesn't double-free the heap memory.\n\n\n```cpp\nclass Inventory {\npublic:\n int* counts;\n int size;\n\n Inventory(int n) : counts(new int[n]), size(n) {}\n\n Inventory(Inventory&& other) noexcept\n : counts(other.counts), size(other.size) {\n // missing something\n }\n\n ~Inventory() { delete[] counts; }\n};\n```\n\n\n

Solution

\n\nThe move constructor copied the pointer but didn't reset the source. Both objects' destructors will try to `delete[]` the same address.\n\n\n```cpp\nInventory(Inventory&& other) noexcept\n : counts(other.counts), size(other.size) {\n other.counts = nullptr;\n other.size = 0;\n}\n```\n\n\n`delete[] nullptr;` is a guaranteed no-op, so the moved-from object's destructor now has nothing to free.\n\n

\n\n**Exercise 4:** Will the compiler generate a move constructor for this class? Explain.\n\n\n```cpp\n#include \n\nclass Order {\npublic:\n int id;\n std::vector prices;\n\n ~Order() { /* nothing */ }\n};\n```\n\n\n

Solution

\n\nNo. The explicit (even empty) destructor suppresses the implicit move constructor and move assignment operator. Without them, attempts to move an `Order` will fall back to the copy operations, which deep-copy the vector.\n\nTwo fixes:\n\n- Remove the empty destructor; the implicit one does the right thing.\n- Or add `Order(Order&&) noexcept = default;` and `Order& operator=(Order&&) noexcept = default;` to bring the implicit move operations back.\n\n

\n\n**Exercise 5:** Predict the output of this program. Which constructor runs at each line?\n\n\n```cpp\n#include \n#include \n\nclass Tracker {\npublic:\n Tracker() { std::cout << \"default\\n\"; }\n Tracker(const Tracker&) { std::cout << \"copy\\n\"; }\n Tracker(Tracker&&) noexcept { std::cout << \"move\\n\"; }\n};\n\nTracker makeOne() {\n Tracker t;\n return t;\n}\n\nint main() {\n Tracker a; // line 1\n Tracker b = a; // line 2\n Tracker c = std::move(a); // line 3\n Tracker d = makeOne(); // line 4\n return 0;\n}\n```\n\n\n**Expected Output (with NRVO):**\n\n\n```shell\ndefault\ncopy\nmove\ndefault\n```\n\n\n

Solution

\n\n- Line 1: default constructor.\n- Line 2: copy constructor, because `a` is an lvalue.\n- Line 3: move constructor, because `std::move(a)` casts to rvalue.\n- Line 4: only one \"default\" prints because NRVO constructs `t` directly into `d`'s memory. Without NRVO, a \"move\" line would also appear.\n\nThe exact NRVO behavior depends on the compiler and optimization level. Older or simpler compilers might show `default` then `move`.\n\n

\n\n**Exercise 6:** Modify the `Buffer` class from Exercise 1 to also provide a copy constructor. Then write code that triggers both the move and copy constructors and prints which one ran.\n\n**Expected Output:**\n\n\n```shell\nctor(3)\ncopy(3)\nmove(3)\ndtor(3)\ndtor(3)\ndtor(0)\n```\n\n\n

Solution

\n\n\n```cpp\n#include \n#include \n#include \n\nclass Buffer {\npublic:\n int* data;\n int size;\n\n Buffer(int n) : data(new int[n]), size(n) {\n std::cout << \"ctor(\" << size << \")\\n\";\n }\n\n Buffer(const Buffer& other) : data(new int[other.size]), size(other.size) {\n std::memcpy(data, other.data, size * sizeof(int));\n std::cout << \"copy(\" << size << \")\\n\";\n }\n\n Buffer(Buffer&& other) noexcept : data(other.data), size(other.size) {\n other.data = nullptr;\n other.size = 0;\n std::cout << \"move(\" << size << \")\\n\";\n }\n\n ~Buffer() {\n std::cout << \"dtor(\" << size << \")\\n\";\n delete[] data;\n }\n};\n\nint main() {\n Buffer a(3);\n Buffer b = a; // copy\n Buffer c = std::move(a); // move\n return 0;\n}\n```\n\n\n

\n\n**Exercise 7:** Why is `noexcept` on the move constructor important when working with `std::vector`? Write a short experiment that demonstrates the difference.\n\n

Solution

\n\n`std::vector` only uses a class's move constructor during reallocation if the move is marked `noexcept`. Otherwise it falls back to copy for exception safety.\n\n\n```cpp\n#include \n#include \n#include \n\nstruct WithNoexcept {\n int* data;\n WithNoexcept() : data(new int[1000]) {}\n WithNoexcept(WithNoexcept&& o) noexcept : data(o.data) { o.data = nullptr; }\n WithNoexcept(const WithNoexcept&) {\n std::cout << \"copy!\\n\";\n }\n ~WithNoexcept() { delete[] data; }\n};\n\nstruct WithoutNoexcept {\n int* data;\n WithoutNoexcept() : data(new int[1000]) {}\n WithoutNoexcept(WithoutNoexcept&& o) : data(o.data) { o.data = nullptr; }\n WithoutNoexcept(const WithoutNoexcept&) {\n std::cout << \"copy!\\n\";\n }\n ~WithoutNoexcept() { delete[] data; }\n};\n\nint main() {\n std::vector v1;\n for (int i = 0; i < 10; i++) v1.push_back(WithNoexcept{});\n std::cout << \"---\\n\";\n std::vector v2;\n for (int i = 0; i < 10; i++) v2.push_back(WithoutNoexcept{});\n}\n```\n\n\nThe second loop prints \"copy!\" lines on every reallocation, while the first does not, because `vector` had no safe move to fall back on.\n\n

\n\n**Exercise 8:** Refactor this class to follow the Rule of Zero. Move semantics should still work.\n\n\n```cpp\n#include \n\nclass Wishlist {\npublic:\n int customerId;\n std::vector productIds;\n\n Wishlist(int id) : customerId(id) {}\n Wishlist(const Wishlist& other)\n : customerId(other.customerId), productIds(other.productIds) {}\n Wishlist(Wishlist&& other) noexcept\n : customerId(other.customerId), productIds(std::move(other.productIds)) {}\n ~Wishlist() {}\n};\n```\n\n\n

Solution

\n\nThe class doesn't own any raw resources directly. Its `std::vector` member already handles its own copy, move, and destruction. Drop all the custom special members:\n\n\n```cpp\n#include \n\nclass Wishlist {\npublic:\n int customerId;\n std::vector productIds;\n\n Wishlist(int id) : customerId(id) {}\n};\n```\n\n\nThe compiler generates a correct copy constructor, move constructor, and destructor, all of which forward to the corresponding `std::vector` operations.\n\n

","pageType":"cpp"}

Move Constructor

Get Premium