Move Semantics Summary

Ownership: the question this chapter kept asking

Every lesson in this chapter circles a single decision. When a resource travels from one part of your program to another, should the program duplicate it, hand it over, or merely look at it? Copy semantics duplicate. Move semantics hand over. Observers only look.

Instead of replaying the lessons one at a time, this recap is organised around that decision, because that is the shape the knowledge takes once you start writing real classes.

What each lesson contributed

L-values and r-values decide what is safe

The compiler does not guess whether stealing is acceptable. It reads the value category of the argument and applies a rule that is always safe.

That is the whole justification for move semantics. A temporary is destroyed at the end of the full expression that created it, so reusing its buffer costs nothing and breaks nothing. A named object might be read on the next line, so the only safe default is to duplicate.

The four hand-over functions in one program

This class implements all four so you can watch the compiler choose between them.

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

class AudioClip
{
public:
    AudioClip(std::string_view title, int frames)
        : m_title{title}
        , m_frames{frames}
        , m_samples{new double[static_cast<std::size_t>(frames)]{}}
    {
        std::cout << "built " << m_title << '\n';
    }

    ~AudioClip()
    {
        delete[] m_samples;
    }

    AudioClip(const AudioClip& source)
        : m_title{source.m_title}
        , m_frames{source.m_frames}
        , m_samples{new double[static_cast<std::size_t>(source.m_frames)]{}}
    {
        std::cout << "copied " << m_title << '\n';
    }

    AudioClip& operator=(const AudioClip& source)
    {
        if (this == &source)
            return *this;

        delete[] m_samples;
        m_title = source.m_title;
        m_frames = source.m_frames;
        m_samples = new double[static_cast<std::size_t>(source.m_frames)]{};

        std::cout << "copy assigned " << m_title << '\n';
        return *this;
    }

    AudioClip(AudioClip&& source) noexcept
        : m_title{std::move(source.m_title)}
        , m_frames{source.m_frames}
        , m_samples{source.m_samples}
    {
        source.m_frames = 0;
        source.m_samples = nullptr;

        std::cout << "handed over " << m_title << '\n';
    }

    AudioClip& operator=(AudioClip&& source) noexcept
    {
        if (this == &source)
            return *this;

        delete[] m_samples;
        m_title = std::move(source.m_title);
        m_frames = source.m_frames;
        m_samples = source.m_samples;
        source.m_frames = 0;
        source.m_samples = nullptr;

        std::cout << "move assigned " << m_title << '\n';
        return *this;
    }

    int frames() const { return m_frames; }

private:
    std::string m_title{};
    int m_frames{0};
    double* m_samples{nullptr};
};

int main()
{
    AudioClip kick{"kick", 240};
    AudioClip snare{"snare", 480};

    AudioClip backup{kick};              // argument is an l-value: copy constructor
    AudioClip carried{std::move(snare)}; // argument is an r-value: move constructor

    AudioClip slot{"silence", 8};
    slot = backup;             // argument is an l-value: copy assignment
    slot = std::move(carried); // argument is an r-value: move assignment

    std::cout << "slot now holds " << slot.frames() << " frames" << '\n';

    return 0;
}

Output:

built kick
built snare
copied kick
handed over snare
built silence
copy assigned kick
move assigned snare
slot now holds 480 frames

The two copy paths call new a second time. The two move paths only reassign a pointer and blank the source, which is why moving is cheap no matter how large the buffer is.

std::move changes the label, not the data

std::move performs no moving at all. It is a cast that relabels an l-value as an r-value so that overload resolution reaches the move overload. Nothing has been transferred until a move constructor or move assignment operator actually runs.

Picking an owner

Moving a std::unique_ptr is the clearest demonstration of the whole chapter, because the class deletes its copy operations, so a transfer is the only thing that can happen.

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

class MixTrack
{
public:
    explicit MixTrack(std::string_view label)
        : m_label{label}
    {
        std::cout << "track " << m_label << " opened" << '\n';
    }

    ~MixTrack()
    {
        std::cout << "track " << m_label << " closed" << '\n';
    }

    const std::string& label() const { return m_label; }

private:
    std::string m_label{};
};

int main()
{
    std::cout << std::boolalpha;

    std::unique_ptr<MixTrack> owner{std::make_unique<MixTrack>("vocals")};
    std::unique_ptr<MixTrack> newOwner{std::move(owner)};

    std::cout << "old handle empty: " << (owner == nullptr) << '\n';
    std::cout << "new handle holds " << newOwner->label() << '\n';

    std::shared_ptr<MixTrack> firstShare{std::make_shared<MixTrack>("drums")};
    {
        std::shared_ptr<MixTrack> secondShare{firstShare};
        std::cout << "owners inside block: " << firstShare.use_count() << '\n';
    }
    std::cout << "owners after block: " << firstShare.use_count() << '\n';

    return 0;
}

Output:

track vocals opened
old handle empty: true
new handle holds vocals
track drums opened
owners inside block: 2
owners after block: 1
track drums closed
track vocals closed

Two facts are worth pinning down from that run. Moving a std::unique_ptr leaves the original handle holding nullptr, so testing it is well defined and dereferencing it is not. And a std::shared_ptr copy raises the owner count while it exists and lowers it again on destruction, with the tracked object surviving until the count reaches zero.

When shared ownership turns into a leak

Reference counting has one failure mode: a group of std::shared_ptr members that reference each other keeps its own count above zero forever.

The program below is broken. It never destroys either object.

#include <iostream>
#include <memory>
#include <string>
#include <string_view>

class MixDesk
{
public:
    explicit MixDesk(std::string_view name)
        : m_name{name}
    {
    }

    ~MixDesk()
    {
        std::cout << m_name << " shut down" << '\n';
    }

    void pairWith(const std::shared_ptr<MixDesk>& partner)
    {
        m_partner = partner;
    }

private:
    std::string m_name{};
    std::shared_ptr<MixDesk> m_partner{};
};

int main()
{
    auto deck{std::make_shared<MixDesk>("deck")};
    auto rack{std::make_shared<MixDesk>("rack")};

    deck->pairWith(rack);
    rack->pairWith(deck);

    std::cout << "leaving main" << '\n';

    return 0;
}

Output:

leaving main

Neither destructor message appears. When main ends, each object is still held by the other's m_partner, so neither count ever falls to zero and the memory is never released.

Switching the back reference to a std::weak_ptr fixes it. A weak pointer does not participate in the count, so it cannot keep anything alive. To use one you call lock(), which returns a std::shared_ptr that is empty if the resource is already gone.

#include <iostream>
#include <memory>
#include <string>
#include <string_view>

class MixDesk
{
public:
    explicit MixDesk(std::string_view name)
        : m_name{name}
    {
    }

    ~MixDesk()
    {
        std::cout << m_name << " shut down" << '\n';
    }

    void pairWith(const std::shared_ptr<MixDesk>& partner)
    {
        m_partner = partner;
    }

    void report() const
    {
        std::shared_ptr<MixDesk> partner{m_partner.lock()};

        if (partner)
            std::cout << m_name << " is paired with " << partner->m_name << '\n';
        else
            std::cout << m_name << " has no partner left" << '\n';
    }

private:
    std::string m_name{};
    std::weak_ptr<MixDesk> m_partner{};
};

int main()
{
    auto deck{std::make_shared<MixDesk>("deck")};
    auto rack{std::make_shared<MixDesk>("rack")};

    deck->pairWith(rack);
    rack->pairWith(deck);

    deck->report();
    rack.reset();
    deck->report();

    std::cout << "leaving main" << '\n';

    return 0;
}

Output:

deck is paired with rack
rack shut down
deck has no partner left
leaving main
deck shut down

Both objects are now released, and the surviving one notices that its partner has gone. Where you only need a yes-or-no answer, expired() reports whether the observed resource is still alive without producing a std::shared_ptr.

Pitfalls the chapter warned about

Summary

• A smart pointer is a composition class that owns heap memory and frees it from its destructor when it goes out of scope.
• Copy semantics duplicate a resource, move semantics transfer ownership of it, and the argument's value category decides which one the compiler picks.
• R-value references, written T&&, bind only to r-values and are what make the move overloads reachable.
• std::move is a cast that lets you invoke move semantics on an l-value you have finished with.
• Deleting the copy constructor and copy assignment operator turns copying into a compile error, which is exactly how std::unique_ptr enforces exclusive ownership.
• Use std::unique_ptr for a single owner, std::shared_ptr for shared ownership by reference count, and std::weak_ptr to observe a shared resource without owning it.
• Prefer std::make_unique() and std::make_shared() over wrapping the result of new.

Key Terminology

• Smart pointer: Composition class that owns a dynamic allocation and releases it in its destructor
• RAII: Tying a resource's lifetime to the lifetime of an object, so cleanup happens on scope exit
• Copy semantics: The rules that duplicate an object, implemented by the copy constructor and copy assignment operator
• Move semantics: The rules that transfer ownership, implemented by the move constructor and move assignment operator
• l-value: An expression naming an object that persists beyond the expression
• r-value: A temporary expression with no name of its own
• r-value reference: A reference declared with && that binds only to r-values
• std::move: A cast that relabels an l-value as an r-value so move overloads become viable
• Move constructor: Builds a new object out of another object's resources
• Move assignment operator: Replaces an existing object's resources with another object's resources
• Moved-from state: The valid but unspecified condition of a source object after its resources are taken
• noexcept: A promise that a function will not throw, which the library relies on before choosing to move
• Deleted function: A member marked = delete, used here to switch copying off entirely
• std::auto_ptr: An early ownership type, deprecated in C++11 and removed in C++17
• std::unique_ptr: Exclusive-ownership smart pointer with copying deleted and moving enabled
• std::make_unique: The preferred factory for std::unique_ptr
• std::shared_ptr: Shared-ownership smart pointer that destroys the resource when its last owner goes away
• std::make_shared: The preferred factory for std::shared_ptr
• Reference counting: The tally of how many std::shared_ptr currently own a resource
• std::weak_ptr: Non-owning observer of a std::shared_ptr resource, accessed through lock()
• Circular reference: A loop of owning pointers whose counts keep each other above zero

Looking Forward

You can now answer the ownership question for any resource your code touches: one owner, several owners, or a plain observer. That answer drives everything else, including which special member functions you write, which smart pointer you reach for, and where a leak could hide. Classes that get it right hand large buffers around at the cost of a pointer assignment and never need a manual delete.

The next chapter turns from a single object's resources to how objects relate to one another. Composition, aggregation, association, and dependency each imply a different ownership answer, and the tools from this chapter are how you express that answer in code.