Move semantics without the mystery

Copying an object that owns heap memory copies the memory. Moving it transfers the ownership: the new object takes the pointer, and the old one is left empty.

std::vector<Quote> a = load_quotes();   // a owns a buffer of a million quotes
std::vector<Quote> b = a;               // copy: allocate, copy 24 MB
std::vector<Quote> c = std::move(a);    // move: copy three pointers, a is now empty

The move constructor of std::vector copies the buffer pointer, the size and the capacity from the source, then sets the source's pointers to null. It does the same amount of work for one element or a billion. That is the whole point: moving is how C++ avoids deep copies when the source is not needed any more.

Nothing at run time. std::move(x) is a cast to an rvalue reference, static_cast<T&&>(x). It tells overload resolution that x may be treated as a temporary, so the move constructor or move assignment is chosen over the copy. The move itself, if there is one, happens in that constructor.

Two consequences:

• std::move on a const object does not move. const T&& does not bind to the move constructor's T&& parameter, so the copy constructor is chosen, silently.
• std::move on a type with no move constructor copies.

After a move, the source is in a valid but unspecified state for standard library types. You may assign to it or destroy it; you should not read its value. Writing std::move(order) and then using order in the next line is a bug that compiles cleanly; clang-tidy's bugprone-use-after-move check finds it.

When a vector grows it allocates a larger buffer and transfers the elements across. It wants to move them. But the standard requires push_back to give the strong exception guarantee: if anything throws, the vector is left as it was. If a move throws half way through, some elements have already left the old buffer and the original state cannot be restored.

So std::vector moves elements only if the move constructor is noexcept (or the type cannot be copied at all). Otherwise it copies them, which can be expensive for elements that own memory. The decision is made through std::move_if_noexcept.

struct Order {
    std::string tag;
    std::vector<Fill> fills;
    Order(Order&&) noexcept = default;          // explicitly noexcept: vector will move
    Order& operator=(Order&&) noexcept = default;
};

Defaulted move constructors are noexcept automatically when all members' moves are. A user-written one is not, unless you say so. A hand-written move constructor without noexcept turns every reallocation into a deep copy. You can check with static_assert(std::is_nothrow_move_constructible_v<Order>).

Often there is no move at all. When a function returns a local object, or a temporary initialises an object of the same type, the compiler constructs the result directly in the destination.

Book build_book(const Snapshot& s) {
    Book b;
    b.load(s);
    return b;              // named return value optimisation: usually no move, no copy
}
Book bk = build_book(snap);  // C++17: initialising from a prvalue is guaranteed elision

Since C++17, initialising from a prvalue such as build_book(snap) is guaranteed to construct in place. Returning a named local is permitted to be elided and in practice almost always is; if not, the local is moved, because return statements treat locals as rvalues.

This is why return std::move(b); is a mistake: it turns the local into an rvalue reference expression, which disables the elision and forces a move.

A function that stores its argument can take it by value and move it into place:

class Strategy {
    std::string name_;
public:
    explicit Strategy(std::string name) : name_(std::move(name)) {}
};
Strategy s1("momentum");        // constructs the parameter from the literal, then moves
Strategy s2(config_name);       // one copy into the parameter, then a move

Callers with temporaries pay a move; callers with lvalues pay one copy, the minimum possible. One function serves both.