Rvalue References, Move Semantics, and Perfect Forwarding

Chapter 1: Universal References

Not every T&& is an rvalue reference. When type deduction is involved, T&& becomes a universal reference (also called a "forwarding reference") — it can bind to lvalues and rvalues:

c++
// Universal reference: T is deduced
template<typename T>
void f(T&& param);     // universal reference

// Rvalue reference: no type deduction on Widget
void f(Widget&& param);  // rvalue reference

// Universal reference: auto deduction
auto&& var = expr;       // universal reference

c++
// NOT universal references (no deduction on &&):
void f(const T&& param);       // rvalue ref (const)
void f(std::vector<T>&& p);  // rvalue ref (not T&&)

// ALSO NOT universal (push_back's T is already known):
template<class T>
class vector {
    void push_back(T&& x);  // rvalue ref, T fixed at class instantiation
};

Chapter 2: std::move on Rvalue Refs, std::forward on Universal Refs

The rule is simple: apply std::move to rvalue references (you know they bind to rvalues), and std::forward to universal references (they might be either):

c++
class Widget {
public:
    // rhs is rvalue ref: always use std::move
    Widget(Widget&& rhs) : name(std::move(rhs.name)) {}

    // newName is universal ref: use std::forward
    template<typename T>
    void setName(T&& newName) {
        name = std::forward<T>(newName);
    }
};

For functions returning by value, apply std::move to rvalue references and std::forward to universal references being returned. But never apply std::move to local variables being returned — this prevents Return Value Optimization (RVO).

c++
// DO NOT do this: prevents RVO
Widget makeWidget() {
    Widget w;
    return std::move(w);  // BAD: inhibits RVO
}

// Just return the local: compiler applies RVO or implicit move
Widget makeWidget() {
    Widget w;
    return w;  // GOOD: RVO or implicit move
}

Chapter 3: The Overloading Danger

Overloading a function that takes a universal reference is almost always a mistake. The universal reference overload is a greedy template that will match nearly anything:

c++
class Person {
public:
    template<typename T>
    explicit Person(T&& n) : name(std::forward<T>(n)) {}

    explicit Person(int idx);  // overload for index lookup
};

Person p("Nancy");     // OK: calls universal ref ctor
Person p(42);           // OK: calls int ctor

short idx = 42;
Person p(idx);            // ERROR: calls universal ref ctor!
                          // short matches T&& better than int

It gets worse with copy/move constructors. If a non-const lvalue of type Person is passed, the universal reference template matches better than the copy constructor (which takes const Person&):

c++
Person p("Nancy");
auto cloneOfP(p);  // calls universal ref ctor, NOT copy ctor!
                   // Template deduces Person&, exact match.
                   // Copy ctor takes const Person& (requires adding const).

Chapter 4: Alternatives to Universal Ref Overloading

If you can't overload on universal references safely, what do you do? Meyers presents several alternatives:

c++
// Option 5: enable_if constrains the template
class Person {
public:
    template<typename T,
             typename = std::enable_if_t<
                 !std::is_base_of_v<Person, std::decay_t<T>>
                 && !std::is_integral_v<std::remove_reference_t<T>>
             >>
    explicit Person(T&& n) : name(std::forward<T>(n)) {}

    explicit Person(int idx);
};

Chapter 5: Reference Collapsing

C++ forbids references to references in source code, but the compiler creates them internally during template instantiation. The reference collapsing rules resolve them:

This is the mechanism that makes universal references and std::forward work. When an lvalue is passed to template<typename T> void f(T&&), T is deduced as Widget&. The parameter type becomes Widget& &&, which collapses to Widget& — an lvalue reference. When an rvalue is passed, T is Widget, and the parameter is Widget&&.

Chapter 6: Don't Assume Move Is Always Better

Move semantics are C++11's marquee performance feature, but there are several situations where moving isn't present, isn't cheap, or isn't used:

Chapter 7: Perfect Forwarding Failures

Perfect forwarding fails when template type deduction deduces the wrong type, or can't deduce at all. Here are the main failure cases:

Chapter 8: Move Semantics Visualized

Watch how move semantics transfer resources instead of copying them. Click to see how a std::string is moved vs copied.

Chapter 9: Beyond

"std::move doesn't move anything. std::forward doesn't forward anything. At runtime, neither does anything at all." — Scott Meyers