Move Semantics

A move constructor takes an rvalue reference, T(T&&), while a copy constructor takes a const lvalue reference, T(const T&). The T&& parameter is what makes the move ctor selected for rvalues, and it is usually marked noexcept.

An rvalue is a value category, usually a temporary expression. An rvalue reference is a type written T&& that can bind to rvalues. A named variable of type T&& is still an lvalue expression inside its scope.

A copy duplicates the owned resource, leaving the source untouched and producing two independent objects. A move transfers ownership of the existing resource to the destination and leaves the source in a valid but unspecified state.

std::move does nothing at runtime — it is purely a compile-time cast of its argument to an rvalue reference (T&&). It moves no data; the actual move happens later, and only if a move constructor or move assignment is then chosen.

std::move unconditionally casts to an rvalue reference. std::forward<T> conditionally preserves the original value category in forwarding-reference templates.

When you return a local variable by value, the compiler treats that local as an rvalue and selects the move constructor automatically — no std::move needed. Writing return std::move(local) is harmful: it pessimizes by blocking copy elision (NRVO).

unique_ptr is exclusive ownership; copy would give two owners and double-delete. Copy ops deleted, move ops defined. Transfer: unique_ptr<T> by value (caller std::moves) or unique_ptr<T>&&. Borrow with T&/const T&. Return by value — move via RVO.

After move, the object is valid but unspecified — you may destroy it, assign to it, or call operations with no preconditions (clear(), empty()), but cannot rely on its value. Standard types are usually empty by convention, not guarantee.

Write Derived(Derived&& o) noexcept : Base(std::move(o)), m_(std::move(o.m_)) {}. std::move(o) is required — o is a named lvalue in the body, so without it the base copy ctor is picked. In move-assign: Base::operator=(std::move(o)); then members.

Copy elision constructs the return value directly in caller storage, skipping copy/move ctor. RVO applies to temporaries (mandatory since C++17 for prvalues); NRVO to named locals (optional). Under mandatory RVO, T x = f(); calls one ctor.

A deleted move ctor still participates in overload resolution (declared, just deleted) and is picked as best match for rvalues — which becomes a hard compile error. T x = std::move(y); fails to compile rather than silently falling back to copy.

Implicitly generated only if none of (dtor, copy ctor/assign, move ctor/assign) is user-declared and all members/bases are movable. Declaring any of those suppresses the implicit move — the class falls back to copy.

std::move(x) returns static_cast<remove_reference_t<T>&&>(x) — for const T it's const T&&. Move ctor takes T&& (non-const), so overload resolution falls through to copy ctor (const T&). Silent copy, no error.

Instead of overloading set(const T&) and set(T&&), write set(T x) { m_ = std::move(x); }. The parameter is built once: copy from lvalue, move from rvalue. The body always moves into the member. Cost: one extra cheap move; benefit: half the overloads.

Self-move (x = std::move(x)) is rare but possible. Moved-from objects stay 'valid but unspecified', so no-op is fine. Copy-and-swap is automatically safe; manual transfer needs if (this != &other) or release-before-acquire ordering.

Declaring a move constructor or move assignment suppresses the implicit copy operations — they become deleted unless you explicitly default or define them. The rule is symmetric: declaring copy ops suppresses the implicit move.

Types whose representation is entirely value-based with no owned heap resource: int, double, small POD structs, std::array<T, N> of trivial T. For these, move is identical to copy because there's no pointer to steal.

No. A built-in array is part of the object's storage, so the generated move element-wise moves/copies every entry. Move is cheap only when the object hands off an external resource — like a heap buffer pointer transferred without touching the data.

Rule of Zero: if all members manage their resources (containers, smart pointers, RAII wrappers), define none of the specials. Rule of Five: if you must define one of (dtor, copy ctor/assign, move ctor/assign), consider all five — manual ownership means Rule of Five.

Inserts (push_back, emplace_back, insert) move from rvalues. vector realloc moves only if noexcept. Algorithms std::move, std::rotate, std::swap move; std::copy, std::copy_n, std::transform copy. C++20 range adaptors use views::move.

Returns an rvalue reference if move ctor is noexcept or the type has no copy ctor; otherwise a const lvalue reference, so the next construction copies. Containers use it on reallocation for the strong exception guarantee.

vector::push_back gives the strong exception guarantee — if a move throws mid-reallocation, vector cannot roll back. So it uses std::move_if_noexcept: noexcept move → move, else → copy. A non-noexcept move silently becomes a copy.

return std::move(local) blocks NRVO/RVO copy elision because std::move(local) is no longer the local object itself, but an rvalue expression referring to it. Without elision you pay a real move call — cheaper than copy, but not zero.

Methods can be qualified by this's value category: T m() & runs on lvalues, T m() && on rvalues. Useful for different bodies — e.g. Buffer::data() && can move out the storage since the object is dying, while Buffer::data() const & returns a const view.

If the source fits in the inline buffer (SSO), move copies inline bytes — no heap pointer to swap. 'Move is free' is wrong for short strings; SSO-move is essentially a copy. Long strings steal the heap pointer (O(1)). SSO threshold varies (~15–23 bytes).

std::vector uses move on reallocation only if move ctor is noexcept (std::is_nothrow_move_constructible). Otherwise it falls back to copy for the strong exception guarantee: a throwing move mid-buffer cannot be undone, copy leaves the original intact.