Modern C++ Memory Management: std::unique_ptr, std::shared_ptr & RAII

2. Step by step: refactor a raw-pointer class to smart pointers

Theory becomes habit the first time you refactor a class that owns a heap object by hand. Here is the classic pre-modern shape — a Car that news an Engine and deletes it in the destructor:

class Engine {
public:
    void start() {}
};

class Car {
    Engine* engine;                       // owning raw pointer
public:
    Car() : engine(new Engine) {}
    ~Car() { delete engine; }             // manual cleanup

    // Compiler-generated copy operations copy the POINTER,
    // so two Cars delete the same Engine. Double free.
};

The bug is not the delete; it is that ownership is invisible. Nothing in the type says Car owns the Engine, so the compiler happily generates copy operations that duplicate the obligation. The refactor makes ownership the type:

#include <memory>
#include <utility>

class Engine {
public:
    void start() {}
};

class Car {
    std::unique_ptr<Engine> engine;       // ownership is now visible
public:
    Car() : engine(std::make_unique<Engine>()) {}

    // unique_ptr is move-only, so Car is move-only too:
    // copies are deleted by the compiler, moves transfer ownership.
    Car(Car&&) noexcept = default;
    Car& operator=(Car&&) noexcept = default;

    Engine& getEngine() { return *engine; }  // observer access, no ownership
};

Three rules finish the refactor anywhere you apply it. Factory functions return std::unique_ptr so the transfer of ownership is in the signature. Functions that only look at an object take a reference or a raw pointer obtained with .get() — observing is free and claims nothing. And a class that holds a unique_ptr almost never needs a handwritten destructor again: the Rule of Zero replaces the Rule of Five.

3. A complete worked example

A texture cache for a game is the canonical shared-ownership problem: many sprites share one loaded texture, the texture must unload when the last user lets go, and the cache itself must not keep everything alive forever. That combination — shared_ptr for users, weak_ptr for the cache — is the whole design:

#include <iostream>
#include <memory>
#include <string>
#include <unordered_map>

struct Texture {
    std::string path;
    explicit Texture(std::string p) : path(std::move(p)) {
        std::cout << "Loaded " << path << "\n";
    }
    ~Texture() { std::cout << "Unloaded " << path << "\n"; }
};

class TextureCache {
public:
    std::shared_ptr<Texture> load(const std::string& path) {
        if (auto it = cache_.find(path); it != cache_.end()) {
            if (auto tex = it->second.lock()) {   // still alive? reuse it
                return tex;
            }
        }
        auto tex = std::make_shared<Texture>(path);
        cache_[path] = tex;                        // cache observes via weak_ptr
        return tex;
    }

private:
    std::unordered_map<std::string, std::weak_ptr<Texture>> cache_;
};

int main() {
    TextureCache cache;
    {
        auto hero = cache.load("hero.png");        // Loaded hero.png
        auto heroAgain = cache.load("hero.png");   // reused, no reload
        std::cout << "Same object: " << (hero == heroAgain) << "\n";
    }   // last shared_ptr dies -> Unloaded hero.png

    auto bg = cache.load("bg.png");   // weak_ptr had expired -> fresh load
    return 0;
}

Run it and the output teaches the semantics: hero.png loads once although load() was called twice, unloads exactly when the inner scope closes, and the cache never extends a texture’s life by a single instruction — because a weak_ptr observes without owning. Swap the cache to shared_ptr and every texture lives until the cache dies; that one-word difference is the most common real-world shared_ptr design error.

Step 3: hand ownership out of factory functions — and handle non-memory resources

Factories complete the pattern: a function that creates an object returns it as a unique_ptr, so the caller receives ownership without ever seeing a raw new. The same mechanism manages resources that are not memory at all. A C file handle has no destructor, so you supply one — a custom deleter — and RAII does the rest:

#include <cstdio>
#include <memory>

struct FileCloser {
    void operator()(std::FILE* f) const {
        if (f) std::fclose(f);
    }
};

// A unique_ptr whose "delete" is fclose
using UniqueFile = std::unique_ptr<std::FILE, FileCloser>;

UniqueFile openLogFile(const char* path) {
    return UniqueFile(std::fopen(path, "a"));   // ownership moves to caller
}

void appendLine(const char* path, const char* line) {
    auto file = openLogFile(path);              // closes on every exit path,
    if (!file) return;                          // including exceptions
    std::fputs(line, file.get());               // .get(): observe, don't own
}

This is the deepest reason the deep-dive below tells you to design ownership first: once ownership is a type, files, sockets, and database handles all get the same one-line cleanup guarantee as heap objects — no finally blocks, no forgotten close on the error path.

4. Troubleshooting

• Compile error: "use of deleted function" when copying. You tried to copy a unique_ptr (or a class containing one, like the Car above). The compiler is enforcing single ownership. Pass the object by reference to share access, std::move it to transfer ownership, or — only if a second genuine owner exists — switch that member to shared_ptr deliberately.
• Crash at program exit, in a destructor, "double free or corruption". Two owners were built from the same raw pointer somewhere: two smart pointers constructed from one new, or a this pointer wrapped by two different managers. Find every place a raw pointer enters a smart pointer; in healthy code it happens exactly once per allocation, at the make_unique/make_shared call.
• LeakSanitizer reports memory "still reachable" at exit. A shared_ptr cycle: A holds B, B holds A, and neither count ever reaches zero. Rebuild with -fsanitize=address,leak, read the cycle in the report, and demote the back-reference to weak_ptr — the fix the deep-dive prescribes, now applied to a leak you can reproduce.
• Segfault when an observer outlives its owner. Something kept a raw pointer or reference (a registry, a callback, a UI widget) after the unique_ptr owner reset or went out of scope. The observer had no way to know the object died. Store a weak_ptr in the observer and lock() it at each use, so expiry is checkable instead of fatal.