RAII、移动语义与 Rule of Five——资源管理的基石

概念介绍

如果你只从这篇文章里带走一个概念，那就是 RAII——Resource Acquisition Is Initialization（资源获取即初始化）。这是 C++ 资源管理的核心理念，也是 C++ 和 C、Python 等语言在资源管理方式上的根本区别。RAII 的核心思想非常简单：资源的获取放在构造函数里，资源的释放在析构函数里，这样当对象的生命周期结束（离开作用域、被 delete 等）时，析构函数自动被调用，资源就自动被释放了。不需要手动调用 free()、close()、release()，不需要 goto cleanup，不需要 finally 块——C++ 的对象生命周期机制替你搞定一切。

RAII 在 C++ 里无处不在。std::vector 的析构函数释放堆内存，std::fstream 的析构函数关闭文件句柄，std::lock_guard 的析构函数释放互斥锁。你每次用 std::string、std::vector、std::unique_ptr 这些标准库类型的时候，你就在享受 RAII 带来的便利——你可能都没意识到，因为资源管理已经被完全自动化了。

但 RAII 只讲了故事的一半——对象怎么释放资源。另一半是对象怎么被传递。在 C++11 之前，对象只有拷贝语义，你想把一个对象传给另一个函数，就得拷贝一份。但对于持有资源的对象来说，拷贝往往是错误的——你不能拷贝一个文件句柄，不能拷贝一个网络连接，也不能拷贝一块独占的 GPU 内存。C++11 引入的移动语义解决了这个问题：与其拷贝资源，不如把资源"搬"到新的对象里，原来的对象变成一个空壳。

移动语义通过右值引用（T&&）和 std::move 来实现。std::move 本质上是一个类型转换——它把一个左值转换成右值引用，告诉编译器"这个对象我之后不用了，你可以偷走它的资源"。移动构造函数和移动赋值运算符就是实际的"偷窃者"——它们把另一个对象的资源指针搬过来，然后把另一个对象的指针置空，这样析构的时候就不会重复释放。

当 RAII 和移动语义结合在一起，就形成了一套完整的资源管理方案：对象在构造时获取资源，可以通过移动语义高效转移所有权，在析构时自动释放资源。如果某种资源不应该被共享或者拷贝（比如独占的设备句柄），你就把拷贝构造函数和拷贝赋值运算符删除，只提供移动操作。

动机

设想这样一个场景：你在写一个图像处理库，图像数据动辄几 MB 到几十 MB。如果你每次传参都要拷贝一份图像数据，那性能就太惨了——一个简单的灰度转换函数可能就要拷贝几十 MB 的数据，而拷贝本身完全是不必要的，你只是想把数据从调用者手里转给被调用函数。但如果不拷贝，用指针或引用传递又很容易出现所有权混乱——谁负责释放内存？如果两个指针指向同一块内存，谁先释放谁就坑了后面那个。

这正是 C++11 之前 C++ 程序员面临的困境，也是移动语义被引入的根本动机。有了移动语义，你可以写出这样的代码：

Image<Gray> process(Image<BGR> img) {
    // img 是按值传递的，调用者会用 std::move 把图像移进来
    // 整个过程只有指针的搬运，没有像素数据的拷贝
    auto result = to_gray(std::move(img));
    return result;  // 返回值也会被移动（NRVO 优化可能连移动都省了）
}

参数 img 按值传递，但因为 Image 是 move-only 的类型，调用者必须用 std::move 把图像移进来（或者传一个临时对象）。函数内部的 to_gray 和 return 都用移动来避免数据拷贝。整个过程从头到尾，像素数据在内存里只有一份，只是在不同的对象之间传递了所有权。

最小示例：一个 Buffer 类的完整生命周期

让我们构建一个简化版的 Buffer 类来展示 RAII、移动语义和 Rule of Five 的完整配合。

#include <cstddef>
#include <cstring>
#include <utility>   // std::move, std::swap
#include <iostream>

class Buffer {
public:
    // 构造函数：获取资源
    explicit Buffer(size_t size)
        : data_(new char[size]), size_(size) {
        std::cout << "Buffer allocated: " << size_ << " bytes\n";
    }

    // 1. 析构函数：释放资源
    ~Buffer() {
        delete[] data_;
        std::cout << "Buffer destroyed\n";
    }

析构函数负责释放构造函数获取的资源。不管对象是怎么离开作用域的——正常返回、异常抛出、甚至 break 跳出循环——析构函数都会被调用。这就是 RAII 的保证。

    // 2. 拷贝构造函数：深拷贝
    Buffer(const Buffer& other)
        : data_(new char[other.size_]), size_(other.size_) {
        std::memcpy(data_, other.data_, size_);
        std::cout << "Buffer copied\n";
    }

    // 3. 拷贝赋值运算符
    Buffer& operator=(const Buffer& other) {
        if (this != &other) {
            delete[] data_;
            size_ = other.size_;
            data_ = new char[size_];
            std::memcpy(data_, other.data_, size_);
        }
        return *this;
    }

拷贝操作创建一份独立的资源副本，两个对象各自管理各自的内存。

    // 4. 移动构造函数：偷走资源
    Buffer(Buffer&& other) noexcept
        : data_(other.data_), size_(other.size_) {
        other.data_ = nullptr;
        other.size_ = 0;
        std::cout << "Buffer moved\n";
    }

    // 5. 移动赋值运算符
    Buffer& operator=(Buffer&& other) noexcept {
        if (this != &other) {
            delete[] data_;            // 释放自己的旧资源
            data_ = other.data_;       // 偷走对方的资源
            size_ = other.size_;
            other.data_ = nullptr;     // 对方变成空壳
            other.size_ = 0;
        }
        return *this;
    }

移动操作偷走另一个对象的资源指针，然后把对方的指针置空。注意移动操作标记为 noexcept，这是因为标准库容器（比如 vector）在扩容时会优先使用移动操作，但只有在移动操作是 noexcept 的时候才会这么做——否则为了强异常安全保证，它们会退回到拷贝操作。所以如果你的移动操作确实不会抛异常（通常都不会），一定要标记 noexcept。

这就是 Rule of Five——如果你需要自定义析构函数、拷贝构造函数、拷贝赋值运算符、移动构造函数、移动赋值运算符中的任何一个，那你很可能需要把五个全写了。因为编译器自动生成的版本对于管理资源的类来说通常是错误的。

现在如果我们不想让 Buffer 被拷贝呢？比如它代表一块独占的设备内存，拷贝根本没意义。这时候我们把拷贝操作删除：

class UniqueBuffer {
public:
    explicit UniqueBuffer(size_t size)
        : data_(new char[size]), size_(size) {}

    ~UniqueBuffer() { delete[] data_; }

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

    // 允许移动
    UniqueBuffer(UniqueBuffer&& other) noexcept
        : data_(other.data_), size_(other.size_) {
        other.data_ = nullptr;
        other.size_ = 0;
    }

    UniqueBuffer& operator=(UniqueBuffer&& other) noexcept {
        if (this != &other) {
            delete[] data_;
            data_ = other.data_;
            size_ = other.size_;
            other.data_ = nullptr;
            other.size_ = 0;
        }
        return *this;
    }

    // 如果确实需要一份拷贝，显式调用 clone()
    UniqueBuffer clone() const {
        UniqueBuffer copy(size_);
        std::memcpy(copy.data_, data_, size_);
        return copy;
    }

private:
    char* data_;
    size_t size_;
};

clone() 方法提供了一个显式的深拷贝接口——你不会意外地拷贝一大块内存，只有在你明确需要的时候才调用它。这种"移动是默认的，拷贝需要显式请求"的设计在现代 C++ 中非常常见。

在更底层的场景下，我们还会遇到placement new（定位 new）和显式析构函数调用。Placement new 不分配内存，而是在你给定的内存地址上构造对象。显式析构函数调用 obj.~T() 则在不释放内存的情况下销毁对象。这两个操作通常配合使用——先在某块内存上构造对象，用完之后显式销毁，但不释放内存。这在你需要精确控制对象生命周期的场景下非常有用，比如内存池、自定义容器、以及——没错——expected<T, E> 的实现。

// placement new：在已有内存上构造对象
alignas(int) char buffer[sizeof(int)];
int* p = new (buffer) int(42);  // 在 buffer 上构造 int
std::cout << *p << '\n';        // 输出 42
p->~int();                       // 显式销毁，但不释放 buffer
// buffer 本身还在栈上，直到离开作用域才被回收

与 edgecv 的关联

edgecv 库中的 Image<F> 就是一个典型的 move-only 类型。它的拷贝操作被显式删除了，只提供移动语义：

template <is_pixel_format format_type> class Image {
public:
    Image(Image&&) noexcept = default;
    Image& operator=(Image&&) noexcept = default;

    Image(const Image&) = delete;
    Image& operator=(const Image&) = delete;

    [[nodiscard]] Image clone() const;
    // ...
};

为什么 Image 不允许拷贝？因为图像数据可能很大，意外拷贝一份几十 MB 的图像是性能杀手。如果你确实需要一份独立的拷贝，你必须显式调用 clone()——这个命名清楚地表达了"这是一次深拷贝，它有代价"的意图。而所有正常的传参和返回都使用移动语义，零拷贝完成所有权转移。

这个设计也影响了 edgecv 的算法函数签名。所有算法都按值接受 Image 参数——这听起来很低效，但实际上因为 Image 是 move-only 的，调用者必须用 std::move 传入（或者传临时对象），所以整个过程只有一次移动，没有拷贝。函数内部对图像的修改也不会影响到调用者的原始图像（因为所有权已经转移了）。这种"按值传递 + move-only"的模式在现代 C++ 中被越来越多地采用，因为它让所有权关系变得非常明确。

expected<T, E> 的实现则展示了 placement new 和显式析构函数调用的实际应用。因为 expected 需要在同一块内存上要么存值、要么存错误，它使用了一个联合体（union）作为存储：

union Storage {
    T val;
    E err;
    Storage() {}
    ~Storage() {}
};
Storage storage_;
bool has_val_;

联合体本身不会自动构造和析构它的成员（因为编译器不知道哪个成员是活跃的），所以 expected 必须手动管理对象的生命周期。构造时用 placement new 在 storage_ 的内存上创建对象：

// 构造值状态
constexpr expected() noexcept(std::is_nothrow_default_constructible_v<T>)
    : has_val_(true) {
    ::new (&storage_.val) T();  // placement new
}

// 构造错误状态
template <typename G = E>
constexpr expected(const unexpected<G>& u)
    requires(std::is_constructible_v<E, const G&>)
    : has_val_(false) {
    ::new (&storage_.err) E(u.error());  // placement new
}

::new (&storage_.val) T() 这行代码的意思是"在 storage_.val 的地址上调用 T 的默认构造函数"。它不会分配任何内存，因为内存已经在 storage_ 里了。同样，析构时需要显式调用析构函数：

void destroy() noexcept {
    if (has_val_) {
        storage_.val.~T();    // 显式析构值
    } else {
        storage_.err.~E();    // 显式析构错误
    }
}

~expected() { destroy(); }

storage_.val.~T() 这行代码调用了 T 的析构函数，但不会释放 storage_ 的内存——因为 storage_ 是 expected 对象的成员，它的内存随着 expected 对象的存在而存在，随着 expected 对象的销毁而被回收。我们只需要确保活跃成员的析构函数被正确调用就行了。

在拷贝赋值和移动赋值运算符中，情况更加复杂——你需要先处理旧状态（是值还是错误），再根据新状态用 placement new 构造新对象或者直接赋值。比如移动赋值运算符：

expected& operator=(expected&& o) noexcept(...) {
    if (this == &o) return *this;
    if (has_val_ && o.has_val_) {
        storage_.val = std::move(o.storage_.val);  // 移动赋值
    } else if (!has_val_ && !o.has_val_) {
        storage_.err = std::move(o.storage_.err);  // 移动赋值
    } else {
        destroy();                                  // 先销毁旧对象
        has_val_ = o.has_val_;
        if (has_val_) {
            ::new (&storage_.val) T(std::move(o.storage_.val));
        } else {
            ::new (&storage_.err) E(std::move(o.storage_.err));
        }
    }
    return *this;
}

最复杂的是状态切换的情况——比如原来存的是值，现在要变成存错误。这时候必须先 destroy() 销毁旧的值对象，然后用 placement new 在同一块内存上构造新的错误对象。这就是 placement new 和显式析构函数调用配合使用的经典场景。

edgecv 的嵌入式模块也大量使用了 RAII 模式。V4L2Camera 在构造函数里打开设备文件 /dev/videoX，在析构函数里关闭文件描述符并释放 DMA 缓冲区。DmaFrameGuard 在析构函数里自动归还 DMA 缓冲区给摄像头驱动。Framebuffer 在构造函数里映射 /dev/fb0 的内存，在析构函数里解除映射并关闭文件。所有这些都是 RAII 的典型应用——你不需要手动管理任何设备资源，只要对象在作用域内，资源就是有效的；对象离开作用域，资源就自动归还。这种设计在嵌入式环境下尤其重要，因为资源泄漏（比如忘记关闭设备文件）可能导致整个系统的设备不可用，而 RAII 提供了最强有力的保障——只要你正确使用了 RAII 包装类，就不可能忘记释放资源。