Modern C++ Tutorial

Appearance

A Deep Dive into RAII: The Cornerstone of Resource Management ​

When I first learned C++, I had absolutely no concept of "resource management"—I would new an object and forget to delete it, open a file and forget to fclose it, lock a mutex and forget to unlock it. As my projects grew, these "forgot to release" bugs started multiplying like cockroaches: spotting one meant there were ten more hiding in the corners (and yes, finding them usually meant I also had to write a post-mortem report, cry). It wasn't until I seriously read Bjarne Stroustrup's book that I realized C++ had long since prepared an elegant solution for us: RAII.

RAII (Resource Acquisition Is Initialization) is the most core resource management concept in C++, and it serves as the foundation for all "automatic cleanup" mechanisms in modern C++, such as smart pointers, lock guards, and file handle wrappers. Once you understand RAII, you aren't just "using tools"—you are grasping the design philosophy behind them. In this article, we will thoroughly master RAII, from its underlying mechanism to practical application.

What Exactly is RAII: A One-Sentence Summary ​

The core idea behind RAII is remarkably simple: acquire resources in the constructor, release them in the destructor. As long as an object is successfully created, the resource is acquired; as soon as the object leaves scope (whether through normal return, an early return, or a thrown exception), the destructor is guaranteed to be called, and the resource is guaranteed to be released.

My first reaction was—huh? Isn't that obvious? But as I thought about it more carefully—hey, that makes perfect sense! I previously wrote drivers, and in C (especially when writing drivers, just thinking about handling 4 to 5 goto statements makes me chuckle), if we rely entirely on programmers remembering to "release resources on every return path" to avoid bugs, I don't think I could survive as a human programmer.

Enough rambling. Let's look at a straightforward example, wrapping a file handle using RAII:

cpp
#include <cstdio>
#include <stdexcept>

class FileHandle {
public:
    explicit FileHandle(const char* path, const char* mode)
        : file_(std::fopen(path, mode))
    {
        if (!file_) {
            throw std::runtime_error("failed to open file");
        }
    }

    ~FileHandle() noexcept {
        if (file_) {
            std::fclose(file_);
        }
    }

    // 禁止拷贝——文件句柄不应该被两个对象同时持有
    FileHandle(const FileHandle&) = delete;
    FileHandle& operator=(const FileHandle&) = delete;

    // 允许移动——所有权可以转移
    FileHandle(FileHandle&& other) noexcept
        : file_(other.file_)
    {
        other.file_ = nullptr;
    }

    FileHandle& operator=(FileHandle&& other) noexcept {
        if (this != &other) {
            if (file_) std::fclose(file_);
            file_ = other.file_;
            other.file_ = nullptr;
        }
        return *this;
    }

    std::FILE* get() const noexcept { return file_; }

private:
    std::FILE* file_;
};

The usage is extremely clean:

cpp
void write_log(const char* msg) {
    FileHandle fh("/tmp/app.log", "a");
    std::fprintf(fh.get(), "%s\n", msg);
    // 函数结束时，fh 的析构自动 fclose
    // 不管是正常返回、提前 return 还是抛异常，都不会泄漏
}

If you are familiar with C, comparing the two reveals a stark difference: in C, every branch that might return early requires a manual fclose, and missing even one results in a file descriptor leak. RAII shifts this "don't forget" burden to the compiler—the destructor is guaranteed to be called (as long as the program exits through normal control flow, rather than directly calling std::exit() or std::abort()). This isn't a convention; it is a guarantee of the C++ language specification.

Stack Unwinding: The Engine Behind RAII ​

The key mechanism that enables RAII is called stack unwinding. When a program leaves a scope (whether because it reached the end of the block, encountered a return statement, or threw an exception), the C++ runtime automatically destroys all successfully constructed local objects within that scope—calling their destructors in reverse order of construction.

This process is a language-level guarantee, not some "best practice" or "compiler optimization." Let's use a concrete example to feel the power of stack unwinding:

cpp
#include <iostream>
#include <stdexcept>

struct Tracer {
    explicit Tracer(const char* name) : name_(name) {
        std::cout << "Tracer(" << name_ << ") 构造\n";
    }
    ~Tracer() noexcept {
        std::cout << "~Tracer(" << name_ << ") 析构\n";
    }
    Tracer(const Tracer&) = delete;
    Tracer& operator=(const Tracer&) = delete;
private:
    const char* name_;
};

void demo_stack_unwinding() {
    Tracer a("a");
    Tracer b("b");
    throw std::runtime_error("boom!");
    Tracer c("c");  // 永远不会执行到这里
}

int main() {
    try {
        demo_stack_unwinding();
    } catch (const std::exception& e) {
        std::cout << "捕获异常: " << e.what() << "\n";
    }
}

Output:

text
Tracer(a) 构造
Tracer(b) 构造
~Tracer(b) 析构
~Tracer(a) 析构
捕获异常: boom!

Notice that after the exception is thrown, b and a are still correctly destructed—and the order is last constructed, first destructed (LIFO). c was never constructed, so it doesn't need destruction. That is the entire secret of stack unwinding: no matter how control flow leaves the scope, all successfully constructed local objects are destroyed in sequence.

We can verify this guarantee with code:

cpp
// GCC 13, -O2 -std=c++11
#include <iostream>
#include <stdexcept>

struct Tracer {
    const char* name;
    explicit Tracer(const char* n) : name(n) {
        std::cout << "Tracer(" << name << ") constructed\n";
    }
    ~Tracer() {
        std::cout << "~Tracer(" << name << ") destroyed\n";
    }
};

void may_throw() {
    throw std::runtime_error("Exception thrown");
}

void test_stack_unwinding() {
    Tracer t1("t1");
    Tracer t2("t2");
    may_throw();  // 异常在这里抛出
    Tracer t3("t3");  // 永远不会执行到这里
}

int main() {
    try {
        test_stack_unwinding();
    } catch (const std::exception& e) {
        std::cout << "Caught: " << e.what() << "\n";
    }
}

Output:

text
Tracer(t1) constructed
Tracer(t2) constructed
~Tracer(t2) destroyed
~Tracer(t1) destroyed
Caught: Exception thrown

⚠️ Destructors should guarantee they do not throw exceptions. If a destructor throws a new exception during exception propagation (stack unwinding), the program calls std::terminate(). Starting with C++11, user-declared destructors are implicitly noexcept(true) (even without explicit specification), and throwing an exception immediately terminates the program. Therefore, destructors should catch and handle all exceptions internally, or move potentially failing operations out of the destructor and provide an explicit interface for error handling.

We can verify this behavior:

cpp
// GCC 13, -O2 -std=c++11
#include <iostream>
#include <type_traits>

struct TestDestructor {
    ~TestDestructor() {
        std::cout << "Destructor called\n";
    }
};

int main() {
    std::cout << "Is destructor noexcept? "
              << std::is_nothrow_destructible<TestDestructor>::value << "\n";
    // 输出：Is destructor noexcept? 1
}

If you attempt to throw an exception in a destructor (even if you explicitly specify noexcept(false)), it will still cause std::terminate() to be called during stack unwinding. This is mandated by the C++ standard to prevent the exception handling mechanism itself from collapsing.

⚠️ Edge cases: The destructor guarantee only applies to "normal control flow exits." If the program calls std::exit(), std::abort(), or _exit(), or is killed by a signal, stack unwinding does not occur, and the destructors of local objects are not called. This is one of the reasons why exceptions should be preferred over std::exit().

Exception Safety Guarantees: The Practical Value of RAII ​

Exception safety is the standard for measuring whether code behaves "correctly" when an exception occurs. The C++ community defines three levels of exception safety guarantees, from weakest to strongest:

Basic Guarantee: After an exception occurs, the program remains in a valid state—there are no resource leaks, and the invariants of all objects still hold. However, the specific state of the program might have changed (for example, a container might have lost some elements). RAII alone helps you automatically achieve this level: as long as all resources are managed by RAII objects, stack unwinding will release them automatically.

Strong Guarantee: After an exception occurs, the program state rolls back to what it was before the operation—either the operation succeeds completely, or it fails completely, with no "half-completed" intermediate state. Implementing the strong guarantee typically requires the copy-and-swap idiom or a transactional rollback mechanism. RAII alone cannot achieve this guarantee, but it is the foundational tool for implementing it.

Nothrow Guarantee: The operation guarantees it will not throw an exception. Destructors, memory deallocation operations, and certain low-level operations (like move int) fall into this category. This is the strongest guarantee, but not all operations can achieve it.

Let's look at a practical example. Suppose we are writing a configuration update function and want it to achieve at least the basic guarantee:

cpp
#include <vector>
#include <string>
#include <fstream>
#include <mutex>

class ConfigManager {
public:
    void update_config(const std::string& key, const std::string& value) {
        // std::lock_guard 是 RAII 的经典应用
        // 构造时上锁，析构时解锁——即使中间抛异常也不会死锁
        std::lock_guard<std::mutex> lock(mutex_);

        // std::vector 和 std::string 都是 RAII 容器
        // 如果 push_back 抛出 bad_alloc，lock_guard 的析构仍然会解锁
        entries_.push_back({key, value});

        // 写入文件也是 RAII：ofstream 析构时自动关闭文件
        std::ofstream out(config_path_, std::ios::app);
        if (out) {
            out << key << "=" << value << "\n";
        }
    }

private:
    std::mutex mutex_;
    std::vector<std::pair<std::string, std::string>> entries_;
    std::string config_path_ = "/tmp/config.ini";
};

In this code, std::lock_guard, std::string, std::vector, and std::ofstream are all RAII-managed resources. No matter which step in the middle of update_config throws an exception, the mutex will be unlocked, the file will be closed, and the memory for the string and vector will be freed—this is the basic exception safety guarantee brought by RAII, acquired almost for free.

The RAII Wrapper Design Pattern ​

In real-world engineering, we often need to write RAII wrappers for various types of resources. Although the C++ standard library already provides many (std::unique_ptr, std::shared_ptr, std::lock_guard, std::fstream, etc.), we will inevitably encounter scenarios it doesn't cover. In such cases, mastering the design pattern of RAII wrappers becomes crucial.

A well-formed RAII wrapper typically follows this design pattern: the constructor acquires the resource (throwing an exception or entering an invalid state if acquisition fails), the destructor releases the resource (must be noexcept), copying is prohibited (to prevent double-free), and moving is allowed (to support ownership transfer). Let's look at another example using a network socket:

cpp
#include <sys/socket.h>
#include <unistd.h>
#include <stdexcept>
#include <utility>

class Socket {
public:
    explicit Socket(int domain, int type, int protocol = 0)
        : fd_(::socket(domain, type, protocol))
    {
        if (fd_ < 0) {
            throw std::runtime_error("socket creation failed");
        }
    }

    ~Socket() noexcept {
        if (fd_ >= 0) {
            ::close(fd_);
        }
    }

    // 禁止拷贝
    Socket(const Socket&) = delete;
    Socket& operator=(const Socket&) = delete;

    // 移动构造
    Socket(Socket&& other) noexcept
        : fd_(other.fd_)
    {
        other.fd_ = -1;
    }

    // 移动赋值
    Socket& operator=(Socket&& other) noexcept {
        if (this != &other) {
            if (fd_ >= 0) ::close(fd_);
            fd_ = other.fd_;
            other.fd_ = -1;
        }
        return *this;
    }

    int get() const noexcept { return fd_; }

private:
    int fd_;
};

You'll notice this pattern is almost identical to the previous FileHandle—acquire, release, prohibit copy, allow move. This is the "four-piece suit" of RAII wrappers. Once you master this pattern, whether you are wrapping database connections, OpenGL textures, SDL windows, or CUDA streams, the routine is exactly the same.

RAII for Mutexes: Why You Should Never Manually Unlock ​

One of the most classic examples of RAII in the C++ standard library is std::lock_guard and std::unique_lock. Many beginners feel that "manual lock/unlock works just fine," and I thought the same way back in the day. That was until I once had a 200-line function with 5 return paths and 3 exception throwing points, and I spent an entire afternoon tracking down an intermittent deadlock bug—after that, I never manually unlocked again.

cpp
#include <mutex>
#include <iostream>

// 错误示范：手动管理锁
void bad_increment(std::mutex& m, int& counter) {
    m.lock();
    if (counter > 100) {
        m.unlock();        // 别忘了每个 return 前都要 unlock
        return;
    }
    counter++;
    // 如果这里抛异常了呢？锁永远不会释放 → 死锁
    m.unlock();            // 最后也别忘了 unlock
}

// 正确做法：RAII 管理
void good_increment(std::mutex& m, int& counter) {
    std::lock_guard<std::mutex> lock(m);
    if (counter > 100) {
        return;  // lock_guard 析构自动 unlock
    }
    counter++;
    // 不管怎么退出，lock_guard 都会 unlock
}

The implementation principle of std::lock_guard is extremely simple—it calls mutex.lock() on construction and mutex.unlock() on destruction. But the reliability improvement it brings is massive. I recommend: anywhere you need to lock, always use an RAII wrapper (lock_guard, unique_lock, or scoped_lock), and never manage lock state manually.

Embedded in Practice: GPIO Pin Management and SPI Chip Select Control ​

The RAII philosophy applies equally well to embedded development. In embedded systems, "resources" are no longer file descriptors or mutexes, but hardware resources like GPIO pins, SPI chip select lines, DMA channels, and I2C buses. Forgetting to release these resources can have more severe consequences than in desktop programs—peripherals freezing, increased power consumption, or even overall system instability.

First, let's look at a GPIO pin management example. We use RAII to bind the pin's lifecycle to the object's lifecycle: initialize the pin on construction, and restore it to a safe state (usually high-impedance input mode) on destruction.

cpp
// gpio_raii.h
#pragma once
#include <cstdint>

enum class GpioDir { kInput, kOutput };

class GpioPin {
public:
    GpioPin(uint8_t pin, GpioDir dir, bool init_level = false) noexcept
        : pin_(pin), dir_(dir)
    {
        // 假设底层 HAL API
        hal_gpio_config(pin_, dir_, /*pull=*/false, init_level);
        if (dir_ == GpioDir::kOutput) {
            hal_gpio_write(pin_, init_level);
        }
    }

    ~GpioPin() noexcept {
        if (moved_) return;
        // 恢复为安全态：输入（高阻），防止引脚浮空导致漏电
        hal_gpio_config(pin_, GpioDir::kInput, false, false);
    }

    // 禁止拷贝，允许移动
    GpioPin(const GpioPin&) = delete;
    GpioPin& operator=(const GpioPin&) = delete;

    GpioPin(GpioPin&& other) noexcept
        : pin_(other.pin_), dir_(other.dir_), moved_(other.moved_)
    {
        other.moved_ = true;
    }

    void write(bool v) noexcept {
        if (dir_ == GpioDir::kOutput) hal_gpio_write(pin_, v);
    }

    bool read() const noexcept { return hal_gpio_read(pin_); }

private:
    uint8_t pin_;
    GpioDir dir_;
    bool moved_ = false;
};

The usage is just as clean as on the desktop:

cpp
void blink_once() {
    GpioPin led(13, GpioDir::kOutput, false);
    led.write(true);
    hal_delay_ms(100);
    led.write(false);
    // 函数结束时，led 自动恢复为安全输入态
}

Managing the SPI chip select (CS) line is another classic RAII scenario. During SPI communication, the CS line needs to be pulled low at the start of each transaction and pulled high at the end. If you forget to pull it high, the slave device will remain busy, and all subsequent communications will fail. We use RAII to bind the CS line state to the transaction:

cpp
class SpiTransaction {
public:
    SpiTransaction(SpiBus& bus, uint8_t cs_pin) noexcept
        : bus_(bus), cs_pin_(cs_pin), active_(true)
    {
        bus_.begin_transaction();
        bus_.set_cs(cs_pin_, false);  // CS active low
    }

    ~SpiTransaction() noexcept {
        if (!active_) return;
        bus_.set_cs(cs_pin_, true);   // CS deassert
        bus_.end_transaction();
    }

    // 禁止拷贝和移动
    SpiTransaction(const SpiTransaction&) = delete;
    SpiTransaction& operator=(const SpiTransaction&) = delete;
    SpiTransaction(SpiTransaction&&) = delete;

private:
    SpiBus& bus_;
    uint8_t cs_pin_;
    bool active_;
};

When using it, we simply place the transaction object within a scope:

cpp
void read_sensor(SpiBus& spi, uint8_t cs) {
    SpiTransaction t(spi, cs);
    spi.transfer(tx_buf, rx_buf, len);
    // 任何 return、break 或异常都会正确释放 CS
}

⚠️ Using RAII in embedded scenarios comes with special constraints: you cannot perform blocking operations in destructors (otherwise real-time performance suffers), you cannot allocate heap memory (many embedded systems lack a heap or have a severely limited one), and creating RAII objects in an ISR (interrupt service routine) requires extreme caution—the stack space in an ISR is limited, and destruction cannot perform complex operations.

Exercise: Designing a Generic ScopeGuard Class ​

As a closing exercise for this article, let's design a generic ScopeGuard class. Its design goal is to wrap any "cleanup action to execute on exit" into an RAII object with minimal overhead. This class is incredibly useful in real-world engineering—when you have operations that "aren't suitable for encapsulating into a dedicated RAII class, but still need guaranteed execution on exit," ScopeGuard is the best choice.

cpp
#include <utility>
#include <exception>
#include <cstdlib>

template <typename F>
class ScopeGuard {
public:
    explicit ScopeGuard(F&& func) noexcept
        : func_(std::move(func)), active_(true)
    {}

    ScopeGuard(ScopeGuard&& other) noexcept
        : func_(std::move(other.func_)), active_(other.active_)
    {
        other.active_ = false;
    }

    ~ScopeGuard() noexcept {
        if (active_) {
            func_();
            // 如果 func_() 抛出异常，由于析构函数标记为 noexcept
            // C++ 运行时会自动调用 std::terminate()
        }
    }

    // 取消守卫——有时候成功后不想执行清理
    void dismiss() noexcept { active_ = false; }

    // 禁止拷贝
    ScopeGuard(const ScopeGuard&) = delete;
    ScopeGuard& operator=(const ScopeGuard&) = delete;

private:
    F func_;
    bool active_;
};

template <typename F>
ScopeGuard<F> make_scope_guard(F&& func) noexcept {
    return ScopeGuard<F>(std::forward<F>(func));
}

Usage example:

cpp
void complex_operation() {
    auto guard = make_scope_guard([]{
        std::cout << "清理工作执行\n";
        cleanup_temp_files();
    });

    // ... 一系列可能失败的操作 ...

    if (error_occurred) {
        return;  // guard 的析构会执行清理
    }

    // 成功了，不需要清理
    guard.dismiss();
}

The implementation of this ScopeGuard is actually directly descended from the classic solution proposed by Andrei Alexandrescu in the 2000s. In later chapters, we will see how the C++ standard codified this pattern into std::scope_exit / std::scope_fail, and how the Boost.Scope library provides even richer functionality.

Verifying Edge Cases: When Destructors Are Not Called ​

To fully understand the applicability boundaries of RAII, we need to be clear about the situations where destructors will not be called. This helps us make correct decisions when designing systems:

cpp
// GCC 13, -O2 -std=c++11
#include <iostream>
#include <cstdlib>

struct Tracer {
    const char* name;
    explicit Tracer(const char* n) : name(n) {
        std::cout << "Tracer(" << name << ") constructed\n";
    }
    ~Tracer() {
        std::cout << "~Tracer(" << name << ") destroyed\n";
    }
};

void test_normal_return() {
    Tracer t("normal");
    return;  // 析构函数会被调用
}

void test_exit() {
    Tracer t("exit");
    std::exit(0);  // 析构函数不会被调用！
}

Output:

text
Normal case:
Tracer(normal) constructed
~Tracer(normal) destroyed

std::exit() case:
Tracer(exit) constructed
(程序直接终止，没有析构输出)

This verification tells us: RAII's guarantees only apply to normal control flow (including exception handling). If the program exits abnormally via std::exit(), std::abort(), _exit(), or signal handling, destructors will not execute. This is another reason why modern C++ recommends using exceptions over std::exit()—exceptions guarantee stack unwinding and resource cleanup, whereas std::exit() does not.

Summary ​

RAII is the cornerstone of C++ resource management. Its core mechanism—acquiring resources on construction and releasing them on destruction—leverages C++'s stack unwinding guarantee, making resource release no longer dependent on a programmer's memory, but rather guaranteed by the language specification. No matter how control flow leaves a scope (normal return, early return, or exception propagation), all RAII objects will be correctly destroyed.

The three levels of exception safety (basic guarantee, strong guarantee, nothrow guarantee) give us a yardstick for measuring code quality. As long as all resources are managed through RAII, basic exception safety is acquired almost "for free." Furthermore, the design pattern for RAII wrappers is highly consistent—acquire resource, prohibit copy, allow move, noexcept destructor. Master this "four-piece suit," and you can write safe wrappers for any type of resource.

The unique_ptr we will dive into next is the most direct embodiment of the RAII philosophy in the realm of smart pointers: zero-overhead exclusive ownership management. Once you understand RAII, understanding unique_ptr will feel completely natural.

References ​

Built with VitePress

Copyright 2025-2026 Charliechen