Move Semantics: Missing noexcept Killed Vector Performance

Every C++ program that handles dynamic memory, containers, or large data structures is paying a hidden tax. Before C++11, returning a vector from a function, inserting a temporary string into a map, or passing ownership of a unique resource all triggered deep copies — full heap allocations, byte-by-byte duplication, and then immediate destruction of the original. For small objects this is noise. For a vector holding a million doubles, it's a performance cliff you fall off without noticing.

Move semantics, introduced in C++11 via rvalue references and codified through move constructors and move assignment operators, solves this by distinguishing between two fundamentally different situations: copying a resource you still need versus transferring a resource you're about to throw away. The language gives the compiler — and you — a way to say 'this object is done with its data, steal it.' No allocation. No byte copy. Just a pointer swap and a null-out.

By the end of this article you'll understand exactly how rvalue references work at the ABI level, how to write correct move constructors (including the subtle noexcept requirement that actually matters for std::vector), how std::move and std::forward differ and why conflating them is dangerous, and the production gotchas that trip up experienced engineers. You'll also be ready for the move-semantics questions that show up in every serious C++ systems interview.

Why Missing noexcept Killed Vector Performance

Move semantics, introduced in C++11, allow resources to be transferred from one object to another without copying. The core mechanic is an rvalue reference (&&) that binds to temporaries or explicitly moved-from objects, enabling a move constructor and move assignment operator to pilfer resources—like a heap-allocated buffer—rather than deep-copy them. This transforms expensive O(n) copies into O(1) pointer swaps.

In practice, move operations must be noexcept to be used by standard containers like std::vector during reallocation. When vector grows, it must move existing elements to new storage. If the move constructor can throw, vector falls back to copy—defeating the entire performance benefit. A single missing noexcept annotation on a move constructor silently forces O(n) copies on every reallocation, turning a fast resize into a performance cliff.

Use move semantics for any type that manages exclusive ownership of a resource: dynamic memory, file handles, sockets. The payoff is dramatic—std::vector reallocation drops from O(n) copies to O(1) moves per element. But the gain is contingent on noexcept. Without it, you get the worst of both worlds: the complexity of move semantics with the performance of copying.

lvalues, rvalues, and rvalue References: The Foundation You Must Nail

Before move semantics makes sense, you need a precise mental model of value categories. An lvalue ('left value') is an expression with a persistent identity — it has a name and an address you can take. int count = 5; count is an lvalue. An rvalue is a temporary expression with no persistent identity — it's either a literal, the result of an arithmetic expression, or a value returned by a function that nobody has bound to a named variable yet. 5, count + 1, or makeBuffer() when the return value isn't captured — those are rvalues.

C++11 introduced the rvalue reference, written T&&. An rvalue reference can only bind to rvalues (with one important exception: std::move). This binding is the compiler's way of detecting 'this thing is temporary — we're safe to steal its guts.' An lvalue reference T& binds to lvalues; an rvalue reference T&& binds to rvalues. They're separate overloads the compiler resolves at compile time with zero runtime cost.

A critical insight: an rvalue reference variable itself is an lvalue once named. If you have Buffer&& temp = makeBuffer();, the expression temp inside your function is an lvalue — it has a name and an address. This is the source of one of the nastiest gotchas in the section below. The value category of an expression is about the expression, not the type.

#include <iostream>
#include <string>

// Overload set that lets us observe which value category the compiler sees
void inspect(const std::string& text) {
    std::cout << "lvalue reference overload called: " << text << "\n";
}

void inspect(std::string&& text) {
    std::cout << "rvalue reference overload called: " << text << "\n";
}

std::string generateGreeting() {
    return "Hello from a temporary";  // Returns a temporary (rvalue)
}

int main() {
    std::string persistentName = "Alice";  // persistentName is an lvalue

    inspect(persistentName);          // Binds to const T& — lvalue overload
    inspect(generateGreeting());      // Binds to T&&    — rvalue overload (temporary)
    inspect("raw string literal");    // Also an rvalue — rvalue overload

    // KEY INSIGHT: an rvalue reference variable is itself an lvalue
    std::string&& capturedTemp = generateGreeting();
    inspect(capturedTemp);            // Calls LVALUE overload — because capturedTemp has a name!
    inspect(std::move(capturedTemp)); // std::move casts it back to rvalue — rvalue overload

    return 0;
}

Value Categories Hierarchy: lvalue, rvalue, xvalue, glvalue, prvalue

Every expression in C++ has two fundamental properties: a type and a value category. The value category determines whether the expression is a locator (something that identifies an object) or a temporary (something that holds a value). C++11 refined the traditional lvalue/rvalue dichotomy into a five-category taxonomy: lvalue (left value), xvalue (eXpiring value), prvalue (pure rvalue), glvalue (generalized lvalue), and rvalue. This hierarchy is critical for understanding when move semantics apply.

• lvalue: An expression with a persistent identity — it refers to an object that exists beyond the current expression. Examples: variable name, array subscript, function call that returns an lvalue reference.
• prvalue: A pure rvalue — a temporary value that does not have an identity, such as a literal, the result of a conceptual operator, or a function call that returns a non-reference type.
• xvalue: An eXpiring value — a glvalue that denotes an object whose resources can be reused (typically after a move). Example: the result of std::move(x) or a cast to T&&.
• glvalue = lvalue + xvalue (generalized lvalue: has identity).
• rvalue = xvalue + prvalue (the set of expressions that can be moved from).

This taxonomy is not just academic. The compiler uses it for overload resolution: a function taking T&& only binds to rvalues (xvalues and prvalues). A function taking const T& binds to everything, but if both overloads exist, the T&& overload wins for rvalues. Understanding the hierarchy lets you predict which constructor (move or copy) the compiler selects.

Writing Correct Move Constructors and Move Assignment Operators

A move constructor transfers ownership of a resource from one object to another, then leaves the source in a 'valid but unspecified' state — typically null/zero/empty. The standard library containers guarantee this: a moved-from std::vector is empty but fully usable. Your own classes must uphold the same contract.

The noexcept specifier on your move constructor is not optional polish — it's load-bearing. std::vector only uses move operations during reallocation if the move constructor is noexcept. If it isn't, vector falls back to copying to preserve the strong exception guarantee. This means if you forget noexcept, your custom type inside a vector will copy during push_back-triggered reallocations. The performance gain you expected from move semantics evaporates silently.

Move assignment is trickier: you must handle self-assignment (buffer = std::move(buffer)) gracefully and release the resource you currently own before stealing the new one. The canonical pattern is: release existing resource, steal the source's pointer, null out the source. The Rule of Five applies: if you define a destructor, copy constructor, copy assignment, move constructor, or move assignment, you almost certainly need all five.

#include <iostream>
#include <cstring>
#include <utility>
#include <stdexcept>

class ManagedBuffer {
public:
    // ── Construction ─────────────────────────────────────────────────────────
    explicit ManagedBuffer(std::size_t capacity)
        : data_(new double[capacity])   // Heap allocation — the expensive resource
        , capacity_(capacity)
        , size_(0)
    {
        std::cout << "[Construct] Allocated " << capacity << " doubles\n";
    }

    // ── Destructor ────────────────────────────────────────────────────────────
    ~ManagedBuffer() {
        delete[] data_;  // data_ may be nullptr after a move — delete[] nullptr is safe
        std::cout << "[Destruct]  Released buffer (capacity=" << capacity_ << ")\n";
    }

    // ── Copy constructor — deep copy, expensive ───────────────────────────────
    ManagedBuffer(const ManagedBuffer& other)
        : data_(new double[other.capacity_])
        , capacity_(other.capacity_)
        , size_(other.size_)
    {
        std::memcpy(data_, other.data_, size_ * sizeof(double));
        std::cout << "[Copy]      Copied " << size_ << " doubles (deep copy!)\n";
    }

    // ── Move constructor — pointer swap, O(1), noexcept IS REQUIRED ───────────
    ManagedBuffer(ManagedBuffer&& other) noexcept
        : data_(other.data_)            // Steal the heap pointer
        , capacity_(other.capacity_)    // Steal metadata
        , size_(other.size_)
    {
        other.data_     = nullptr;  // Leave source in valid-but-empty state
        other.capacity_ = 0;        // Source destructor will call delete[] nullptr — safe
        other.size_     = 0;
        std::cout << "[Move]      Moved buffer — no allocation, O(1)\n";
    }

    // ── Copy assignment — Rule of Five ────────────────────────────────────────
    ManagedBuffer& operator=(const ManagedBuffer& other) {
        if (this == &other) return *this;         // Self-assignment guard
        ManagedBuffer temp(other);                // Copy-and-swap idiom
        swap(temp);
        return *this;
    }

    // ── Move assignment — release ours, steal theirs ──────────────────────────
    ManagedBuffer& operator=(ManagedBuffer&& other) noexcept {
        if (this == &other) return *this;         // Self-move guard (rare but must handle)
        delete[] data_;           // Release OUR resource first
        data_     = other.data_;  // Steal source's pointer
        capacity_ = other.capacity_;
        size_     = other.size_;
        other.data_     = nullptr;  // Disarm the source
        other.capacity_ = 0;
        other.size_     = 0;
        std::cout << "[MoveAssign] Transferred ownership\n";
        return *this;
    }

    void push(double value) {
        if (size_ >= capacity_) throw std::runtime_error("Buffer full");
        data_[size_++] = value;
    }

    std::size_t size()     const { return size_; }
    std::size_t capacity() const { return capacity_; }

private:
    void swap(ManagedBuffer& other) noexcept {
        std::swap(data_,     other.data_);
        std::swap(capacity_, other.capacity_);
        std::swap(size_,     other.size_);
    }

    double*     data_;
    std::size_t capacity_;
    std::size_t size_;
};

// Factory function — caller gets ownership transferred via move, no copy
ManagedBuffer createSensorReadings(std::size_t count) {
    ManagedBuffer readings(count);
    for (std::size_t i = 0; i < count; ++i)
        readings.push(static_cast<double>(i) * 1.5);
    return readings;  // NRVO may elide this move entirely — but move is the fallback
}

int main() {
    std::cout << "=== Factory call (NRVO or move) ===\n";
    ManagedBuffer sensorData = createSensorReadings(4);
    std::cout << "sensorData has " << sensorData.size() << " readings\n\n";

    std::cout << "=== Explicit move into new owner ===\n";
    ManagedBuffer archiveBuffer(10);
    archiveBuffer = std::move(sensorData);  // Move assignment — sensorData is now empty
    std::cout << "archiveBuffer size: " << archiveBuffer.size()
              << "  sensorData size: "  << sensorData.size() << "\n\n";

    std::cout << "=== Destructors run as stack unwinds ===\n";
    return 0;
}

Rule of Three vs. Five vs. Zero: When to Write Each Special Member Function

The C++ rule of three, five, and zero guide when you need to define the special member functions (destructor, copy/move constructors, copy/move assignment operators).

Rule of Three: If your class manages a resource (e.g., raw memory, file handle) and you need to define a destructor, copy constructor, or copy assignment operator, you likely need all three. This prevents resource leaks and double-frees.

Rule of Five: With C++11, move semantics introduced move constructor and move assignment. If you need custom copy operations (Rule of Three), you should also implement move operations to enable efficient ownership transfer. Always mark them noexcept for container compatibility.

Rule of Zero: The modern best practice: design your class to not directly manage resources. Use RAII objects like std::vector, std::string, std::unique_ptr as members. The compiler will generate correct (and often optimal) special members for you. This avoids the boilerplate and error-prone manual resource management.

Which rule to apply depends on your class's responsibilities. Here's a comparison:

In practice, the Rule of Zero should be your default. Only drop down to Rule of Five when you have proven (via profiling) that the extra control yields significant performance gain or when you're implementing a low-level container yourself. Rule of Three is largely obsoleted by C++11; prefer Rule of Five if you must manage resources.

Vector Reallocation: The Move-Fallback Decision Workflow

When you call push_back on a std::vector and the internal capacity is exhausted, the vector must reallocate: allocate a new (larger) memory block, transfer existing elements, deallocate the old block. The key decision in this critical path is whether to move or copy each element during the transfer. The choice depends on the noexcept qualification of the move constructor.

std::vector guarantees the strong exception guarantee: if an exception is thrown during reallocation, the original vector contents remain intact. To uphold this, vector uses std::move_if_noexcept, which selects the move constructor only if it is noexcept. Otherwise, it falls back to the copy constructor, which is guaranteed not to throw (assuming the copied types don't throw during copy, but that's typical for well-behaved types).

Here is the decision workflow depicted as a flowchart:

noexcept Impact: Benchmarking Vector Reallocation Performance

The performance difference between a noexcept move constructor and a non-noexcept one is dramatic. When a vector reallocates, the fallback to copy causes O(n) deep copies of each element, each requiring a heap allocation. With noexcept move, the vector performs O(1) pointer swaps per element. Below is a benchmark comparing the latency of 10,000 sequential push_back calls (triggering several reallocations) for a simple wrapper type holding a 64-byte buffer.

Benchmark setup: GCC 12, -O2, M1 Pro, single-threaded. The type SmallBuffer has a 64-byte std::array (no heap allocation to isolate the copy/move cost). Three variants: - Move (noexcept): Move constructor noexcept. - Move (without noexcept): Move constructor but not noexcept. - Copy only: No move constructor, only copy constructor.

The numbers speak clearly: the non-noexcept move version performs similarly to the copy-only version because each reallocation copies every element. The noexcept version is roughly 10x faster and incurs far fewer allocations.

Why such a difference? Copying constructs a new element (with a new heap allocation) and copies the old content, then destroys the old element (freeing its memory). Those two heap ops per element add up. Move just swaps three pointers and nulls out the source — no heap interaction.

Takeaway for production: If your type is stored in a std::vector and used in a performance-sensitive path, ensure its move constructor is noexcept. Use static_assert to enforce it. Profile with real sizes to confirm the benefit.

std::move vs std::forward: When to Use Each (and Why Confusing Them Breaks Code)

Two utilities dominate move semantics code: std::move and std::forward. They look similar — both are casts, both live in <utility>, neither generates machine code. But they serve completely different purposes, and using one where the other belongs causes either silent copies or double-move bugs.

std::move is an unconditional cast to rvalue reference. It doesn't move anything — it just tells the compiler 'treat this as a temporary.' Use it when you explicitly want to transfer ownership and you know you're done with the object. After std::move, treat the source as if it's in an unspecified state.

std::forward is a conditional cast — it preserves the original value category of a template argument. It's used exclusively inside template functions with forwarding references (T&& where T is a deduced template parameter). The canonical use case is a factory or wrapper function that needs to forward arguments to another constructor or function without changing their value category. Calling std::forward on a non-deduced T&& is a bug, not a feature. And calling std::move in a forwarding context strips lvalue-ness from lvalue arguments, corrupting the call site's object.

#include <iostream>
#include <string>
#include <memory>
#include <utility>
#include <vector>

struct NetworkPacket {
    std::string  payload;
    int          priority;

    // Observe which constructor fires
    NetworkPacket(std::string p, int prio)
        : payload(std::move(p)), priority(prio) {
        std::cout << "  [Construct] payload='" << payload << "' priority=" << priority << "\n";
    }

    NetworkPacket(const NetworkPacket& other)
        : payload(other.payload), priority(other.priority) {
        std::cout << "  [Copy]      payload='" << other.payload << "'\n";
    }

    NetworkPacket(NetworkPacket&& other) noexcept
        : payload(std::move(other.payload)), priority(other.priority) {
        std::cout << "  [Move]      payload='" << payload << "'\n";
    }
};

// ── Perfect forwarding factory — preserves value category of every argument ──
template <typename T, typename... Args>
std::unique_ptr<T> makeUnique(Args&&... args) {
    // std::forward preserves: lvalue args stay lvalues, rvalue args stay rvalues
    return std::unique_ptr<T>(new T(std::forward<Args>(args)...));
}

// ── WRONG version — std::move unconditionally strips lvalue-ness ─────────────
template <typename T, typename... Args>
std::unique_ptr<T> makeUniqueBroken(Args&&... args) {
    // Using std::move here moves from lvalue arguments at the call site!
    return std::unique_ptr<T>(new T(std::move(args)...));
}

int main() {
    std::string sharedPayload = "CONNECT /api/v1 HTTP/1.1";

    std::cout << "── Correct perfect forwarding ──\n";
    // sharedPayload is an lvalue — forward preserves it as lvalue — copy ctor fires
    auto packet1 = makeUnique<NetworkPacket>(sharedPayload, 1);
    std::cout << "  sharedPayload still valid: '" << sharedPayload << "'\n\n";

    std::cout << "── Forward with explicit move — intentional steal ──\n";
    // std::move casts sharedPayload to rvalue before entering makeUnique
    // forward then preserves that rvalue — move ctor fires
    auto packet2 = makeUnique<NetworkPacket>(std::move(sharedPayload), 2);
    std::cout << "  sharedPayload after move: '" << sharedPayload << "' (empty — expected)\n\n";

    std::cout << "── Broken version steals lvalue arguments silently ──\n";
    std::string importantData = "DO NOT STEAL ME";
    auto packet3 = makeUniqueBroken<NetworkPacket>(importantData, 3);
    // importantData has been moved-from! Caller doesn't expect this.
    std::cout << "  importantData after makeUniqueBroken: '" << importantData << "' (STOLEN!)\n";

    return 0;
}

Production Internals: NRVO, Moved-From State, and When Not to Use std::move

Named Return Value Optimization (NRVO) is the compiler's right to construct a local return variable directly in the caller's storage — eliminating both the copy and the move entirely. This is not a hint or a maybe — modern compilers apply NRVO aggressively under -O1 and above. If you write return std::move(localBuffer) in a function returning ManagedBuffer, you break NRVO. The std::move prevents the compiler from seeing the return as a construction-in-place candidate, so you pay for a move that you didn't need to pay for at all.

The moved-from state contract is 'valid but unspecified.' For standard library types this means: a moved-from std::string is empty; a moved-from std::vector is empty; a moved-from std::unique_ptr is null. For your own types, you choose the invariant — but whatever state the destructor runs on must be valid and safe. Dereferencing a moved-from pointer, calling non-trivial methods on a moved-from object, or assuming any specific value — all undefined behavior.

In multithreaded code, move semantics doesn't give you thread safety for free. Moving a std::shared_ptr between threads without synchronization is still a data race on the reference count. And std::atomic types are not movable at all — the hardware atomicity guarantee requires a fixed address. These are the edges where move semantics meets real systems constraints.

#include <iostream>
#include <string>
#include <vector>
#include <utility>

struct TraceableString {
    std::string value;

    explicit TraceableString(std::string v) : value(std::move(v)) {}

    TraceableString(TraceableString&& other) noexcept : value(std::move(other.value)) {
        std::cout << "  [Move ctor fired]\n";
    }

    TraceableString(const TraceableString& other) : value(other.value) {
        std::cout << "  [Copy ctor fired — this is expensive!]\n";
    }
};

// ── NRVO candidate: compiler builds result directly in caller's frame ─────────
TraceableString buildMessage_NVROFriendly() {
    TraceableString message("Server started on port 8080");
    message.value += " [OK]";
    return message;  // NRVO applies — no move, no copy
}

// ── NRVO BROKEN by explicit std::move — triggers move ctor unnecessarily ──────
TraceableString buildMessage_NRVOBroken() {
    TraceableString message("Server started on port 8080");
    message.value += " [OK]";
    return std::move(message);  // std::move defeats NRVO — move ctor fires
}

// ── Demonstrating the moved-from contract ────────────────────────────────────
void demonstrateMovedFromState() {
    std::vector<int> sensorReadings = {10, 20, 30, 40, 50};
    std::cout << "  Before move: size=" << sensorReadings.size() << "\n";

    std::vector<int> archive = std::move(sensorReadings);
    // sensorReadings is now in a valid-but-empty state — safe to check, unsafe to read elements
    std::cout << "  After move:  sensorReadings.size()=" << sensorReadings.size()
              << "  archive.size()=" << archive.size() << "\n";

    // Safe: reassigning a moved-from object brings it back to a defined state
    sensorReadings = {99, 100};
    std::cout << "  After reassign: sensorReadings.size()=" << sensorReadings.size() << "\n";
}

// ── Returning std::move from a function parameter — legitimate use ────────────
std::string appendSuffix(std::string base, const std::string& suffix) {
    base += suffix;  // Mutates local copy (base was passed by value — it's ours)
    return base;     // NRVO or implicit move — do NOT write std::move(base) here
}

int main() {
    std::cout << "── NRVO-friendly return (expect no move ctor) ──\n";
    TraceableString msg1 = buildMessage_NVROFriendly();
    std::cout << "  Result: " << msg1.value << "\n\n";

    std::cout << "── NRVO broken by std::move (move ctor fires) ──\n";
    TraceableString msg2 = buildMessage_NRVOBroken();
    std::cout << "  Result: " << msg2.value << "\n\n";

    std::cout << "── Moved-from state demonstration ──\n";
    demonstrateMovedFromState();
    std::cout << "\n";

    std::cout << "── Pass-by-value + return (sink pattern) ──\n";
    std::string endpoint = "wss://api.example.com";
    std::string full = appendSuffix(endpoint, "/ws/v2");
    std::cout << "  endpoint still valid: " << endpoint << "\n";
    std::cout << "  full: " << full << "\n";

    return 0;
}

Move Semantics Edge Cases: const, Thread Safety, and Compiler Optimizations

Moving from a const object is a cruel illusion. std::move(const_string) casts to const std::string&& — which doesn't bind to a move constructor (that takes std::string&&), only to the copy constructor (taking const std::string&). The cast does nothing useful; you get a copy. In production, you'll see this when a function accepts a const std::string& parameter and someone tries to std::move it internally — the copy is inevitable.

Thread safety: moving a std::shared_ptr between threads without synchronization is a data race on the reference count. The shared_ptr's control block is modified during move (decrement source, increment dest) — two threads doing that concurrently without a mutex is undefined behavior. Move semantics is not a thread-safety mechanism.

Compiler optimizations: NRVO is the primary candidate, but there's also copy elision for prvalues (guaranteed in C++17). The compiler may apply the 'as-if' rule and eliminate moves entirely if the resulting object has no observable side effects. However, if the return type is different from the local type, implicit move does not apply. In that case you need explicit std::move. Understanding where the compiler can and cannot elide moves is critical for performance tuning.

#include <iostream>
#include <string>
#include <utility>

struct Tracker {
    std::string data;
    Tracker(std::string d) : data(std::move(d)) {}
    Tracker(const Tracker&) { std::cout << "Copy constructor called\n"; }
    Tracker(Tracker&&) noexcept { std::cout << "Move constructor called\n"; }
};

int main() {
    const Tracker ct("hello");
    std::cout << "Moving from const object: ";
    Tracker moved = std::move(ct);  // Expect "Copy constructor called"
    return 0;
}

Move Semantics in Templates: Universal References, Type Traits, and SFINAE

When you write template<typename T> void foo(T&& arg), the T&& is not an rvalue reference — it's a forwarding reference (also called a universal reference). The value category of the argument determines what T deduces to: if you pass an lvalue of type int, T deduces to int&, making the parameter int& && which collapses to int&. If you pass an rvalue, T deduces to int, making the parameter int&&. This collapsing mechanism is why std::forward works: it uses the deduced type to restore the original value category.

You can use type traits to constrain your templates to only accept types that are movable or nothrow movable. std::enable_if with std::is_move_constructible prevents instantiation with non-movable types. Similarly, you can write std::enable_if<std::is_nothrow_move_constructible<T>::value> to force exception safety.

A common mistake is using std::move on a forwarding reference inside the function body: this unconditionally casts the argument to rvalue, breaking perfect forwarding. Use std::forward<T>(arg) instead. Another pitfall: relying on implicit move when the return type doesn't match the local type — in that case, explicit std::move is required.

#include <iostream>
#include <type_traits>
#include <memory>
#include <utility>

struct MoveOnly {
    MoveOnly() = default;
    MoveOnly(const MoveOnly&) = delete;
    MoveOnly& operator=(const MoveOnly&) = delete;
    MoveOnly(MoveOnly&&) noexcept = default;
    MoveOnly& operator=(MoveOnly&&) noexcept = default;
};

struct Copyable {
    Copyable() = default;
    Copyable(const Copyable&) { std::cout << "Copy\n"; }
    Copyable& operator=(const Copyable&) { std::cout << "Copy assign\n"; return *this; }
};

// Factory that conditionally enables only for movable types
template<typename T, typename... Args,
         typename = std::enable_if_t<std::is_move_constructible<T>::value>>
std::unique_ptr<T> makeMovable(Args&&... args) {
    return std::unique_ptr<T>(new T(std::forward<Args>(args)...));
}

int main() {
    // Compiles: MoveOnly is move constructible
    auto ptr1 = makeMovable<MoveOnly>();
    
    // Compiles: Copyable is move constructible too (implicitly)
    Copyable c;
    auto ptr2 = makeMovable<Copyable>(c);
    
    // The following would fail to compile if uncommented:
    // auto ptr3 = makeMovable<Copyable>(std::move(c)); // OK
    // auto ptr4 = makeMovable<const Copyable>(c); // Fails if Copyable not copyable? 
    
    return 0;
}

Why Move Semantics: It's Not About Convenience, It's About Cache Misses

Move semantics exists because copying heap-allocated resources is the single most expensive thing you do in C++. Every copy of a std::vector or std::string triggers a malloc/memcpy/free cycle. That's thousands of CPU cycles. Worse: it pollutes the cache hierarchy. Move semantics swaps pointers: four bytes on a 64-bit machine. No allocation. No cache invalidation. No thread contention on the allocator lock. That's the whole point. You're not writing elegant code; you're avoiding a performance cliff. When a temporary object is about to die, you steal its heap pointer. You leave the original in a valid-but-empty state. This is not an optimization trick — it's the default mechanism for containers like std::vector, std::string, and std::unique_ptr. Your code already uses it whether you know it or not.

// io.thecodeforge
#include <iostream>
#include <vector>
#include <chrono>

struct BigData {
    std::vector<int> data;
    BigData(size_t size) : data(size, 42) {}
};

int main() {
    auto start = std::chrono::high_resolution_clock::now();
    
    BigData source(10'000'000);
    BigData copy = source;           // 80 MB memcpy + malloc
    auto t1 = std::chrono::high_resolution_clock::now();
    
    BigData moved = std::move(source); // 4 byte pointer swap
    auto t2 = std::chrono::high_resolution_clock::now();

    std::cout << "Copy:  " 
              << std::chrono::duration_cast<std::chrono::microseconds>(t1 - start).count()
              << " μs\n";
    std::cout << "Move:  " 
              << std::chrono::duration_cast<std::chrono::microseconds>(t2 - t1).count()
              << " μs\n";
    return 0;
}

Why Move Semantics Only Apply to Rvalues: The Safety Contract

You can safely steal from an rvalue because it's a temporary — nobody holds a reference to it. After the expression ends, it's gone. If you stole from an lvalue, you'd leave a living object in a moved-from state, and some other code might try to read it. That's undefined behavior. This is why std::move doesn't actually move anything — it casts an lvalue to an rvalue reference. It tells the compiler: 'I promise I won't use this source again.' The standard library honors that contract: moved-from containers are valid but unspecified. They must be destructible and assignable, but you cannot assume they are empty. The vector might still hold a pointer to freed memory if the move constructor didn't null it. That's your responsibility. You either write proper move constructors that set source.m_ptr = nullptr, or you accept the risk. Rvalues get the green light because they expire. Lvalues need your explicit promise via std::move.

// io.thecodeforge
#include <iostream>
#include <string>

void observe(const std::string& s) {
    std::cout << s << "\n";  // Must not crash
}

int main() {
    std::string source = "Hello";
    std::string target = std::move(source);  // You promised source is disposable
    
    // source is now in "valid but unspecified" state
    // This is safe per standard, but content is undefined
    observe(source);  // Might print "", "Hello", or garbage
    
    // Reset before reuse:
    source = "I'm alive again";
    observe(source);  // Fine
    return 0;
}