Move semantics: steal instead of copy

The problem: expensive copies

A std::vector<std::string> with a lakh names holds a big heap buffer. Copying it means allocating a new buffer and copying every string. But often the source is about to disappear anyway: a temporary result from a function, or a local variable you will never use again. Copying in those cases is pure waste. Moving instead just takes over the source's buffer pointer and leaves the source empty: a few pointer assignments, no matter how big the vector is.

lvalues and rvalues

An lvalue is an expression that names an object with an identity you can refer to again, like a variable name. An rvalue is a temporary value that is about to disappear, like the result of a + b or a function returning by value. C++ automatically moves from rvalues because nobody can use them afterwards. For lvalues it copies, because you might still use them, unless you say otherwise with std::move.

std::string makeName() { return "Asha Verma"; }

std::string a = "hello";
std::string b = a;               // a is an lvalue: COPY
std::string c = makeName();      // temporary: MOVE (or no copy at all, see below)
std::string d = std::move(a);    // std::move: MOVE; a is now valid but unspecified (usually empty)

Rvalue references (T&&)

An rvalue reference, written T&&, is a reference that binds only to rvalues. Classes use it to write a move constructor and a move assignment operator: overloads that are chosen when the source is an rvalue, and that steal its resources.

class Buffer {
public:
    explicit Buffer(std::size_t n) : size_(n), data_(new int[n]{}) {}
    ~Buffer() { delete[] data_; }

    Buffer(Buffer&& other) noexcept                 // move constructor
        : size_(other.size_), data_(other.data_) {
        other.size_ = 0;
        other.data_ = nullptr;                      // leave the source safe to destroy
    }
    Buffer& operator=(Buffer&& other) noexcept {    // move assignment
        if (this != &other) {
            delete[] data_;
            data_ = other.data_;
            size_ = other.size_;
            other.data_ = nullptr;
            other.size_ = 0;
        }
        return *this;
    }
    Buffer(const Buffer&) = delete;                 // copying not supported in this example
    Buffer& operator=(const Buffer&) = delete;
private:
    std::size_t size_;
    int* data_;
};

Why noexcept matters

When std::vector grows, it must transfer its elements to the new buffer. If the element's move constructor is marked noexcept, vector moves them (fast). If not, vector copies them instead, to keep its strong exception guarantee. So always mark move operations noexcept when they cannot throw (they usually cannot).

Return values: no std::move needed

std::vector<int> loadMarks() {
    std::vector<int> result(100000, 0);
    return result;               // do NOT write return std::move(result);
}

Since C++17, when you return a temporary (prvalue) like return std::string("x"); or initialise from one, the copy or move is guaranteed not to happen at all: the object is built directly in its final place. This is guaranteed copy elision.

Using moves in everyday code

std::vector<std::string> names;
std::string line = readLine();
names.push_back(std::move(line));     // line is not needed any more: move it in

class Student {
public:
    explicit Student(std::string name) : name_(std::move(name)) {}   // "sink" parameter
private:
    std::string name_;
};

Rule of zero, again

If your class only holds members like std::string, std::vector and std::unique_ptr, the compiler generates correct move operations for you. You write move constructors yourself only in low-level resource classes. Note that declaring a destructor or copy operation yourself stops the compiler from generating moves, and then the class silently copies instead of moving.