`std::unique_ptr`: Exclusive Ownership and Move Semantics

The Burden of Manual Memory Management

You're well-acquainted with C-style manual memory management using new and delete. While it gives you control, it also places the entire burden of correctness on you.

Consider this simple C-style code:

class Widget { /* ... */ };

void process_widget() {
    Widget* raw_ptr = new Widget(); // Acquire resource

    // ... lots of work ...
    // what if an exception is thrown here?

    delete raw_ptr; // Release resource
}

This pattern is fragile for several reasons:

• Forgetting delete: A simple mistake leads to a memory leak.
• Double delete: Deleting the same pointer twice leads to undefined behavior.
• Exception Safety: As we saw in the last lesson, if an exception occurs between acquisition (new) and release (delete), the delete statement is skipped, and the resource is leaked.

RAII solves this by tying the resource's lifetime to an object's scope. std::unique_ptr is the standard library's embodiment of this principle for single-owner resources.

std::unique_ptr: RAII for Exclusive Ownership

std::unique_ptr is a class template that wraps a raw pointer. It holds the sole responsibility—the exclusive ownership—of that pointer. When the unique_ptr object is destroyed (e.g., when it goes out of scope), its destructor automatically calls delete on the raw pointer it owns.

This completely automates cleanup and makes our code robust. The following video introduces unique_ptr, contrasts it with error-prone raw pointer code, and shows how to refactor to use it.

As you saw, the best practice for creating a unique_ptr is using the std::make_unique helper function:

#include <memory>
#include <iostream>

class Widget {
public:
    Widget() { std::cout << "Widget created\n"; }
    ~Widget() { std::cout << "Widget destroyed\n"; }
    void do_work() { std::cout << "Doing work...\n"; }
};

void process_widget_modern() {
    // Create a Widget on the heap, owned by a unique_ptr.
    auto widget_ptr = std::make_unique<Widget>();

    widget_ptr->do_work(); // Use it like a normal pointer.

} // `widget_ptr` goes out of scope here. Its destructor is called, which deletes the Widget.

int main() {
    std::cout << "Entering main\n";
    process_widget_modern();
    std::cout << "Exiting main\n";
    return 0;
}

When you run this, the output will be:

Entering main
Widget created
Doing work...
Widget destroyed
Exiting main

The Widget is automatically destroyed, no matter how process_widget_modern exits (by returning normally or by an exception).

The Core Principle: Move-Only Semantics

The "unique" in unique_ptr is strictly enforced. There can only ever be one owner. What happens if you try to copy it?

auto p1 = std::make_unique<Widget>();
auto p2 = p1; // COMPILE ERROR!

This code will not compile. The compiler stops you because the copy constructor and copy assignment operator of std::unique_ptr are explicitly deleted. This is a key design feature. If copying were allowed, you would have two unique_ptrs thinking they own the same resource, leading to a double delete when they both go out of scope.

So, how do you transfer ownership from one unique_ptr to another? You move it.

The mechanism for this is std::move. It's a signal to the compiler that you intend to transfer the resource from one object to another.

auto p1 = std::make_unique<Widget>();
// p1 owns the Widget

auto p2 = std::move(p1); // Transfer ownership from p1 to p2
// Now, p2 owns the Widget. p1 is now empty (holds nullptr).

// p1->do_work(); // This would be a runtime error (segmentation fault)!
if (p2) {
    p2->do_work();
}

This is fundamental to understanding unique_ptr: it has move-only semantics. It can be moved, but not copied. This is how it enforces exclusive ownership at compile time.

This is also how functions can return unique_ptrs efficiently. The compiler automatically treats a returned local variable as a "move," so no explicit std::move is needed.

std::unique_ptr<Widget> create_widget() {
    return std::make_unique<Widget>(); // Ownership is moved out of the function
}

void consume_widget() {
    auto my_widget = create_widget(); // and moved into my_widget
    my_widget->do_work();
}

Under the Hood: A Look at the Implementation

To truly understand move semantics, it helps to see how unique_ptr is implemented. It's surprisingly simple. Let's look at a minimal implementation.

The core of the move constructor is this:

// Simplified move constructor
unique_ptr(unique_ptr&& src)
   : mPtr{src.mPtr}   // 1. Copy the raw pointer value from the source.
{
    src.mPtr = nullptr; // 2. Null out the source pointer.
}

This operation is incredibly cheap—it's just two pointer assignments. You're not moving the Widget in memory; you're only moving the ownership of it.

The mCoding video you watched earlier also builds a simple unique_ptr from scratch. Reviewing this section will solidify your understanding of the move constructor and other member functions.

Performance and ABI Implications

One of the design goals of unique_ptr is to be a zero-overhead abstraction. But what does that mean?

1. Memory Overhead: With its default deleter, sizeof(std::unique_ptr<T>) is exactly equal to sizeof(T*). It doesn't store any extra data beyond the raw pointer it manages.
2. Runtime Overhead: Accessing the object via -> or * compiles down to the same single machine instruction as dereferencing a raw pointer.

However, there is a subtle but important difference in how a unique_ptr and a raw pointer are handled by the compiler, which stems from the fact that unique_ptr has a non-trivial destructor. This has consequences for the Application Binary Interface (ABI), which dictates how functions are called, parameters are passed, etc.

On Linux, the System V ABI for x86-64 has a specific rule: objects with non-trivial destructors (like unique_ptr) cannot be passed in CPU registers; they must be passed on the stack.

Why? The previous lesson on stack unwinding gives us the answer. If an exception is thrown, the unwinder needs to find and destroy objects with automatic storage duration. To do this, those objects must have a stable address on the stack. Registers are volatile and don't have stable addresses. A raw pointer, having a trivial destructor, has no such requirement and can be freely passed in a register.

This can lead to surprising performance differences. The following Stack Overflow discussion, inspired by a CppCon talk, dives deep into this exact issue.

This is a fantastic example of how a high-level C++ feature's design (unique_ptr's destructor for RAII) has direct, observable consequences at the machine code level due to system-level standards like the ABI.

Flexibility: Custom Deleters

Finally, unique_ptr is not just for memory from new. It can manage any resource that has a single owner and needs to be released. We saw this in the previous lesson with our FILE* wrapper. std::unique_ptr formalizes this with custom deleters.

A custom deleter is provided as the second template argument. This allows you to specify a different cleanup function instead of the default delete.

#include <cstdio> // For C-style file I/O

// A deleter for FILE* from fopen
struct FileCloser {
    void operator()(FILE* f) const {
        if (f) {
            fclose(f);
            std::cout << "File closed.\n";
        }
    }
};

void process_c_file() {
    // The type is now std::unique_ptr<FILE, FileCloser>
    std::unique_ptr<FILE, FileCloser> file_ptr(fopen("test.txt", "w"));
    if (file_ptr) {
        fprintf(file_ptr.get(), "Hello from unique_ptr!");
    }
} // file_ptr goes out of scope, its FileCloser is called, which calls fclose.

An interesting detail is that if the deleter is a stateless object (like our FileCloser or a stateless lambda), the compiler can use an optimization (Empty Base Optimization or [[no_unique_address]] in C++20) to ensure the unique_ptr still has zero size overhead. If the deleter has state (like a function pointer), the unique_ptr will be larger.

This flexibility makes std::unique_ptr an incredibly powerful and general-purpose tool for RAII.

class Packet {
public:
    virtual ~Packet() = default;
    virtual void process() = 0;
};

class DataPacket : public Packet {
public:
    void process() override { /* ... process data ... */ }
};

class ControlPacket : public Packet {
public:
    void process() override { /* ... process control info ... */ }
};

// This function creates a packet on the heap and returns ownership.
??? create_packet(/*...args...*/) {
    if (/* condition for data */) {
        return std::make_unique<DataPacket>();
    } else {
        return std::make_unique<ControlPacket>();
    }
}

// This function receives a packet and takes ownership to process it.
void process_and_own_packet(??? p) {
    p->process();
    // Packet is automatically destroyed when 'p' goes out of scope.
}

void manager_function() {
    auto my_packet = create_packet(/*...args...*/);
    process_and_own_packet(std::move(my_packet));

    // What is the state of my_packet here? Is it safe to use?
}

Conclusion

You have now analyzed std::unique_ptr, the C++ standard library's primary tool for expressing exclusive ownership. It provides compile-time safety and runtime efficiency, making it a true zero-overhead abstraction for most use cases.

Key Takeaways:

• std::unique_ptr automates resource cleanup via RAII for a single owner.
• Its core design is exclusive ownership, enforced by move-only semantics (deleted copy operations, enabled move operations).
• Ownership is transferred cheaply using std::move, which only moves the internal pointer, not the managed object.
• For the default deleter, it has zero memory overhead (sizeof(ptr) == sizeof(raw_ptr)).
• Due to its non-trivial destructor, the ABI mandates it be passed on the stack, unlike raw pointers which can use registers. This is a direct consequence of the requirements for stack unwinding.
• Custom deleters make it a flexible RAII wrapper for any type of resource.

What's Next?

std::unique_ptr is perfect when a resource has a clear, single owner. But what happens when ownership needs to be shared among multiple parts of your program? How do you know when the last owner is finished so the resource can be released? In our next lesson, we will dissect std::shared_ptr, which solves this problem using a technique called reference counting. We'll examine its implementation, performance trade-offs, and the internal "control block" that makes it all work.