CppCon 2019 | Back to Basics: RAII and The Rule of Zero

本文整理了Arthur O\’Dwyer在CppCon 2019上关于RAII的演讲，演讲的slides可以在此链接进行下载。

在C++程序中，我们往往需要管理各种各样的资源。资源通常包括以下几种：

• Allocated memory (malloc/free, new/delete, new[]/delete[])
• POSIX file handles (open/close)
• C File handles (fopen/fcolse)
• Mutex locks (pthread_mutex_lock/pthread_mutex_unlock)
• C++ threads (spawn/join)

上面这些资源，有些的管理权是独占的（比如mutex locks），而另一些的管理权则可以是共享的（比如堆、文件句柄等）。重要的是，程序需要采取一些明确的措施才能释放资源。下面，我们将以经典的堆分配为例，来说明资源管理中的若干问题。

下面的代码实现了一个非常朴素的向量类，它提供了

push_back

接口，每次调用

push_back

都会释放旧资源，然后申请新资源。

class NaiveVector {public:int *ptr_;size_t size_;NaiveVector()  : ptr_(nullptr), size_(0) {}void push_back(int newvalue) {int *newptr = new int[size_ + 1];std::copy(ptr_, ptr_ + size_, newptr);delete [] ptr_;ptr_ = newptr;ptr_[size_++] = newvalue;}};

在上面代码的第6行，构造函数正确地初始化了

ptr_

和

size_

。在

push_back

函数的实现中，也正确地实现了资源的申请和释放。到目前为止，一切看起来都如我们所愿，没有发生任何的资源泄漏。

{NaiveVector vec;   // here ptr_ is initialized with 0 elementsvec.push_back(1);  // ptr_ is correctly updated with 1 elementvec.push_back(2);  // ptr_ is correctly updated with 2 elements}

考虑上面这块代码，在作用域中，我们创建了一个

NaiveVector

类型的对象

vec

，然后调用两次

push_back

函数。每次调用

push_back

，

ptr_

所指向的资源将会被释放，然后指向一个新申请的资源。当离开作用域时，局部对象

vec

被销毁，但此时

vec

对象中的

ptr_

成员仍然指向着某个资源，在销毁

vec

对象时，该资源并没有被释放，这就导致了资源的泄露。

显然，为了防止资源泄漏，我们需要在销毁

vec

对象时正确地释放掉它所管理的那些资源。注意到在创建某个类型的对象时，编译器会调用该类型的构造函数；相应地，当某个对象的生命周期结束时，编译器会调用析构函数来销毁该类型的对象。还是以上面的代码为例，在第2行编译器调用

NaiveVector

的构造函数创建对象；在第5行离开作用域时，编译器会调用析构函数销毁局部对象

vec

。因此，我们只需要实现一个析构函数并在其中释放掉所管理的资源，就能避免对象析构时的资源泄漏。新版的

NaiveVector

实现如下所示，其中第1456c行实现了析构函数。

class NaiveVector {public:int *ptr_;size_t size_;NaiveVector()  : ptr_(nullptr), size_(0) {}void push_back(int newvalue) {int *newptr = new int[size_ + 1];std::copy(ptr_, ptr_ + size_, newptr);delete [] ptr_;ptr_ = newptr;ptr_[size_++] = newvalue;}~NaiveVector() { delete [] ptr_; }};

然而，实现了析构函数以后，

NaiveVector

仍然会导致资源泄漏，这是由对象的拷贝操作引起的。如果我们没有为该类实现拷贝构造函数，那么编译器会生成一个合成的拷贝构造函数。合成拷贝构造函数的行为非常简单，它会逐一拷贝对象中的每个成员。对于指针类型的成员来说，它仅拷贝指针的值。

{NaiveVector v;v.push_back(1);{NaiveVector w = v;}std::cout << v[0] << \"\\n\";}

上面代码的第5行调用了

NaiveVector

类型的合成拷贝构造函数。拷贝操作完成后，

w.ptr_

和

v.ptr_

指向同一块内存资源。当执行到第6行时，离开了

w

对象的作用域，编译器会调用

w

的析构函数来释放

w.ptr_

所管理的资源并销毁该对象。由于

w.ptr_

和

ad8v.ptr_

指向同一块资源，而这一块资源已经被

w

的析构函数释放掉了，因此在第7行对

v[0]

的访问就成了未定义行为。此外，在第8行离开

v

对象的作用域时，编译器又会调用

v

的析构函数来释放资源，这就导致了对同一块资源的重复释放，这同样是一个未定义行为。

正确地实现拷贝构造函数可以解决上述问题。换句话说，如果我们为某个类实现了析构函数，那么我们同样需要为它实现拷贝构造函数。析构函数负责释放资源以避免泄漏，而拷贝构造函数负责拷贝资源以避免重复释放。下面的代码实现了相应的拷贝构造函数。

class NaiveVector {public:int *ptr_;size_t size_;NaiveVector()  : ptr_(nullptr), size_(0) {}~NaiveVector() { delete [] ptr_; }NaiveVector(const NaiveVector& rhs) {ptr_ = new int[rhs.size_];size_ = rhs.size_;std::copy(rhs.ptr_, rhs.ptr_ + size_, ptr_);}};

仅仅实现拷贝构造函数还不够，我们还需要实现拷贝赋值运算符。类似于合成拷贝构造函数，合成拷贝赋值运算符同样是拷贝每个成员的值。当离开对象的作用域时，合成拷贝赋值运算符同样会导致资源的重复释放。因此，我们还需要实现拷贝赋值运算符。下面的代码正确地实现了拷贝赋值运算符。

class NaiveVector {int *ptr_;size_t size_;public:NaiveVector()  : ptr_(nullptr), size_(0) {}~NaiveVector() { delete [] ptr_; }NaiveVector(const NaiveVector& rhs) {ptr_ = new int[rhs.size_];size_ = rhs.size_;std::copy(rhs.ptr_, rhs.ptr_ + size_, ptr_);}NaiveVector& operator=(const NaiveVector& rhs) {NaiveVector copy = rhs;copy.swap(*this);return *this;}};

综合上面的分析，我们可以得出结论——如果一个类需要直接管理某些资源，那么我们就要收手动地为这个类实现三个特殊的成员函数：

• 析构函数，负责释放资源
• 拷贝构造函数，负责拷贝资源
• 拷贝赋值运算符，负责释放运算符左边的资源并拷贝运算符右面的资源
  这就是大名鼎鼎的The Rule of Three。另外，需要注意的是，我们可以通过拷贝并交换原语（copy-and-swap idiom）来实现拷贝复制运算符。欸，为什么需要通过拷贝并交换来实现拷贝赋值运算符呢？直接像下面这样，先释放旧资源再申请新资源不行吗？

NaiveVector& NaiveVector::operator=(c56const NaiveVector& rhs) {delete ptr_;ptr_ = new int[rhs.size_];size_ = rhs.size_;std::copy(rhs.ptr_, rhs.ptr_ + size_, ptr_);return *this;}

答案显然是不行，因为上面的这种实现不能正确地处理自我赋值（self-assignment）的情况。在自我赋值的情况下，

ptr_

所指向的资源被释放，新申请的资源中包含的均是未定义的值，此时显然已经无法进行正确的拷贝操作。而在下面的拷贝并交换实现中，我们在修改

*this

对象之前就对

rhs

进行了一次完整的拷贝（通过拷贝构造函数），这就避免了自我赋值中的陷阱。

NaiveVector& NaiveVector::operator=(const NaiveVector& rhs) {NaiveVector copy(rhs);copy.swap(*this);return *this;}

RAII的全称为Resource Acquisition Is Initialization，意思是资源获取即初始化。表面上看，RAII是关于初始化的，但实际上RAII更注重于资源的正确释放。使用RAII有助于我们写出异常安全的代码。考虑下面的代码，在第3行我们申请了内存资源，如果此时程序抛出异常，那么已经申请的资源就不能正确地被释放，从而导致内存泄漏。

int main() {try {int *arr = new int[4];ad0throw std::runtime_error(\"for example\");delete [] arr; // clean up} catch (const std::exception& e) {std::cout << \"Caught an exception: \" << e.what() << \"\\n\";}return 0;}

为了避免这个问题，我们可以使用RAII技术，将资源释放操作放到析构函数中。这样的话，即使程序抛出了异常，也能够正确地释放掉相应的资源。

struct RAIIPtr {int *ptr_;RAIIPtr(int *p) ptr_(p) {}~RAIIPtr() { delete [] ptr_; }};int main() {try {RAIIPtr arr = new int[4];throw std::runtime_error(\"for example\");} catch (const std::exception& e) {std::cout << \"Caught an exception: \" << e.what() << \"\\n\";}return 0;}

注意上面的

RAIIPtr

实现仍然可能会导致资源泄漏，因为我们没有实现拷贝构造函数和拷贝赋值运算符。当然，通过向拷贝构造函数和拷贝赋值运算符添加

=delete

，我们可以让

RAIIPtr

变成不可拷贝的（non-copyable）。

struct RAIIPtr {int *ptr_;RAIIPtr(int *p) ptr_(p) {}~RAIIPtr() { delete [] ptr_; }RAIIPtr(const RAIIPtr&) = delete;RAIIPtr& operator=(const RAIIPtr&) = delete;};

使用

=delete

之后，编译器就不会为

RAIIPtr

生成任何拷贝构造函数和拷贝赋值运算符，任何拷贝操作都会被拒绝。类似地，我们可以通过

=default

来让编译器生成默认的成员函数。如果某个类不直接管理任何资源，而仅使用

vector

和

string

之类的库，那么我们就不应该为它编写任何特殊的成员函数，使用默认的即可。这就是我们所说的The Rule of Zero。

移动语义和The Rule of Five

C++11中引入了右值引用和移动语义，由此产生了移动构造函数和移动拷贝赋值运算符。一般来说，移动一个对象比拷贝一个对象的速度要快，尤其是当对象较大的时候。

class NaiveVector {// copy constructorNaiveVector(const NaiveVector& rhs) {ptr_ = new int[rhs.size_];size_  = rhs.size_;std::copy(rhs.ptr_, rhs.ptr_ + size_, ptr_);}// move constructorNaiveVector(NaiveVector&& rhs) {ptr_ = std::exchange(rhs.ptr_, nullptr);size_ = std::exchange(rhs.size_, 0);}};

因此，为了保证正确性和性能，我们有了The Rule of Five——如果某个类直接管理某种资源，那么我们可能需要实现以下五个特殊的成2332员函数：

• 析构函数，负责释放资源
• 拷贝构造函数，负责拷贝资源
• 移动构造函数，负责转移资源的所有权
• 拷贝赋值运算符，负责释放运算符左边的资源并拷贝运算符右边的资源
• 移动赋值运算符，负责释放运算符左边的资源并转移运算符右边资源的所有权

需要注意的是，拷贝赋值运算符和移动赋值运算符的实现几乎一致，仅有微小的差别：

NaiveVector& NaiveVector::operator=(const NaiveVector& rhs) {NaiveVector copy(rhs);copy.swap(*this);return *this;}NaiveVector& NaiveVector::operator=(NaiveVector&& rhs) {NaiveVector copy(std::move(rhs));copy.swap(*this);return *this;}

因此，一种想法是只实现一个赋值运算符（by-value assignment operator），将拷贝和移动的选择权交给函数的调用者，如下所示。不过这种实现方式并不常见，最好还是将拷贝赋值和移动赋值分开实现，毕竟STL就是这么做的 ? 。

NaiveVector& NaiveVector::operator=(NaiveVector copy) {copy.swap(*this);return *this;}

根据上面的描述，我们衍生出The Rule of Four (and a half)——如果某个类直接管理某种资源，那么我们可能需要实现以下四个特殊的成员函数，以确保正确性和性能：

• 析构函数，负责释放资源
• 拷贝构造函数，负责拷贝资源
• 移动构造函数，负责转移资源的所有权
• by-value assignment operator，负责释放运算符左边的资源并转移运算符右边资源的所有权
  另外，我们还需要实现两个版本的

  swap

  函数，一个作为成员函数，一个作为非成员函数。根据The Rule of Four (and a half)，我们实现了一个较为高效的

  Vec

  类：

class Vec {public:int *ptr_;int size_;Vec(const Vec& rhs) {ptr_ = new int[rhs.size_];size_ = rhs.size_;std::copy(rhs.ptr_, rhs.ptr_ + size_, ptr_);}Vec(Vec&& rhs) noexcept {ptr_ = std::exchange(rhs.ptr_, nullptr);size_ = std::exchange(rhs.size_, 0);}// two-argument swap, to make efficiently \"std::swappable\"friend void swap(Vec& a, Vec& b) noexcept {a.swap(b);}~Vec() {delete [] ptr_;}Vec& operator=(Vec copy) {copy.swap(*this);return *this;}// member swap, for simplicityvoid swap(Vec& rhs) noexcept {using std::swap;swap(ptr_, rhs.ptr_);swap(size_, rhs.size_);}};

通过将原始指针更换为

unique_ptr

，我们可以实现一个接近The Rule of Zero的

Vec

类：

class Vec {public:std::unique_ptr<int[]> uptr_;int size_;// copy the resourceVec(const Vec& rhs) {uptr_ = std::make_unique<int[]>(rhs.size_);size_ = rhs.size_;std::copy(rhs.uptr_, rhs.uptr_ + rhs.size_, uptr_);}// transfer ownershipVec(Vec&& rhs) noexcept = default;friend void swap(Vec& a, Vec& b) noexcept {a.swap(b);}// free the resource~Vec() = default;// free and transfer ownershipVec& operator=(Vec copy) {copy.swap(*this);return *this;}// swap ownershipvoid swap(Vec& rhs) noexcept {using std::swap;swap(uptr_, rhs.uptr_);swap(size_, rhs.size_);}};

当然，真正的The Rule of Zero，还是得靠

std::vector

来实现：

class Vec {public:std::vector<int> vec_;Vec(const Vec& rhs) = default;Vec(Vec&& rhs) noexcept = default;Vec& operator=(const Vec& rhs) = default;Vec& operator=(Vec&& rhs) = default;~Vec() = default;// swap ownership// now only for performance, not correctnessvoid swap(Vec& rhs) noexcept {vec_.swap(rhs.vec_);}friend void swap(Vec& a, Vec& b) {a.swap(b);}};

总结一下，如果某个类需要直接管理资源，那么为了保证正确性，我们需要为该类实现析构函数、拷贝构造函数和拷贝赋值运算符（The Rule of Three）；为了保证性能，我们还可以实现移动构造函数和移动拷贝赋值运算符（The Rule of Five）。如果某个类不直接管理资源，那么就不要实现任何特殊的成员函数（The Rule of Zero）。