Question bank — Move semantics — rvalue references (&&), std - move, std - forward

template<class T> void wrap(T&& a){ callee(a); }
``` ::: Bug: `a` has a name, so `callee(a)` always passes an lvalue and copies even when a temporary was given. Fix: `callee(std::forward<T>(a));`.
 
```cpp
Str(Str&& o) noexcept : data(o.data), len(o.len) {}
``` ::: Missing `o.data = nullptr; o.len = 0;`. Both objects now own the same buffer; two destructors `delete[]` it twice → double-free UB. Reset the source to empty-but-valid.
 
```cpp
Str c = std::move(a);
std::cout << a;   // print old contents
``` ::: Reading a moved-from object's value: after the move `a`'s value is unspecified, so this prints garbage. Only reassign or destroy `a` afterward.
 
```cpp
void take(std::string&& s){ store(s); }
``` ::: Inside `take`, the named `s` is an lvalue, so `store(s)` copies. To actually move, write `store(std::move(s))`.
 
```cpp
template<class T> void log(T&& x){ sink(std::move(x)); }
``` ::: Using `std::move` on a forwarding reference unconditionally strips lvalue-ness: an lvalue caller gets its object silently plundered. Use `std::forward<T>(x)` so lvalues stay copies.
 
```cpp
void concrete(Widget&& w){ use(std::forward<Widget>(w)); }
``` ::: `std::forward` misused: `Widget&&` here is a *fixed* rvalue reference, not a deduced forwarding reference, so there is no value category to restore. Use `std::move(w)` instead.
 
```cpp
Str& operator=(Str&& o){ delete[] data; data=o.data; len=o.len; return *this; }
``` ::: No self-move guard and no reset of `o`. On self-assignment `delete[] data` then reading `o.data` reads freed memory; also `o` still owns the buffer. The copy-and-swap `operator=(Str o)` from the parent avoids both problems (see [[Rule of Five]]).
 
---
 
## Why questions
 
Why does overloading on `const T&` versus `T&&` let the compiler auto-select copy vs move? ::: Because a named lvalue can only bind to `const T&`, while a temporary rvalue prefers the better-matching `T&&`; the binding rules route "named thing → copy" and "temporary → move" automatically.
 
Why must a moved-from object be *valid* and not merely emptied? ::: Its destructor still runs, and other code may assign to it; leaving it in a coherent state (e.g. `nullptr`, `len=0`) guarantees the destructor and reassignment behave, satisfying RAII (Resource Acquisition Is Initialization) — see [[RAII and Ownership]].
 
Why does `std::forward` need the template parameter `T` written explicitly as `std::forward<T>(x)`? ::: `T` encodes how the caller passed the argument (deduced to `U&` for lvalues, `U` for rvalues); `forward` reads that `T` to pick the right cast, so it cannot deduce it from `x` alone (`x` is always an lvalue inside).
 
Why does reference collapsing exist at all? ::: Deduction can produce "reference to reference" like `U& &&`; the collapsing rules ($T\&\ \&\& \to T\&$, $T\&\&\ \&\& \to T\&\&$) turn those into a single reference so forwarding references have well-defined types — see [[Reference collapsing]].
 
Why is taking the assignment parameter *by value* (`operator=(Buf o)`) elegant? ::: The by-value parameter is built by copy or move as appropriate, then a cheap `swap` transfers guts and the parameter's destructor frees the old data — one function covers copy- and move-assignment and is self-assignment safe.
 
Why does `std::move` on a `const` object fall back to copying? ::: `std::move(constObj)` yields a `const T&&`, which cannot bind to the non-const `T&&` move constructor, so overload resolution picks `const T&` (copy). Declaring things `const` quietly forbids moving them.
 
---
 
## Edge cases
 
What does `std::move` do to a fundamental type like `int`? ::: Nothing useful — `int` has no heap to steal, so the "move" is just a copy of the bits; `std::move` is harmless but pointless here.
 
Calling `wrapper(makeStr())` where `T` deduces to a non-reference — what value category does `std::forward` produce? ::: An rvalue. `T` is a plain type, so `static_cast<T&&>` is an rvalue-ref cast, letting `callee` select the move overload.
 
Calling `wrapper(x)` with a named `x` — what does `T` deduce to and what is forwarded? ::: `T` deduces to `U&`; reference collapsing makes `T&&` into `U&`, so `std::forward` produces an lvalue and `callee` copies — exactly the caller's intent.
 
What happens if a move constructor throws while `std::vector` is reallocating a `noexcept`-less type? ::: The vector never risks it — because the move is not `noexcept`, it copies elements instead, so a throw mid-way leaves the original vector intact (strong guarantee) at the cost of copy performance.
 
Is `Str c = std::move(a);` legal if `Str` has a deleted move constructor but a valid copy constructor? ::: It depends: an explicitly *deleted* move constructor participates in overload resolution and wins for the rvalue, making it a compile error; a merely *absent* move constructor lets the copy constructor be chosen instead.
 
What is the value category of the temporary returned by `std::move(x)`? ::: An xvalue (an "expiring" rvalue, defined in the glossary above) — it names an object whose resources may be reused, which is precisely what lets it bind to `T&&`.
 
Can you move from a `const std::string&&`? ::: No — `const` blocks it. The move constructor needs a non-const source to null out its pointer, so a `const` rvalue matches only the copy constructor.
 
---
 
> [!recall]- One-line self-test
> If a "move" gave you no speedup, name the three usual culprits.
> Culprits ::: No move constructor exists (silent copy); the move constructor isn't `noexcept` (vector copies); or you wrote `std::move`/`std::forward` on the wrong thing (const object, named `&&` param, or elision you accidentally disabled).