C++ 核心指南之资源管理（上）
C++ 核心指南（C++ Core Guidelines）是由 Bjarne Stroustrup、Herb Sutter 等顶尖 C++ 专家创建的一份 C++ 指南、规则及最佳实践。旨在帮助大家正确、高效地使用“现代 C++”。
这份指南侧重于接口、资源管理、内存管理、并发等 High-level 主题。遵循这些规则可以最大程度地保证静态类型安全，避免资源泄露及常见的错误，使得程序运行得更快、更好。
R. Resource Management
本章的基本目标是：不产生资源泄漏，不持有不再需要的资源。资源是指需要申请和（显式或隐式）释放的任何东西，如内存、文件句柄、套接字、锁等。如果一个实体“拥有”资源，则意味着该实体负责释放资源。在个别场景下，资源泄露是可以接受的。例如有足够的内存处理最大的输入，或者出于性能优化考虑，只申请不释放，本章的规则不适用于这类特殊情况。
- 资源管理规则总结
- R.1: 通过资源句柄和 RAII 自动管理资源
- R.2: 在接口中，裸指针只用来表示单个对象
- R.3: 裸指针（T*）不拥有资源
- R.4: 裸引用（T&）不拥有资源
- R.5: 优先使用对象，非必要不在堆上分配
- R.6: 避免使用非 const 的全局变量
R.1: 通过资源句柄和 RAII 自动管理资源
避免泄露以及手动管理资源的复杂性。C++ 的构造/析构反映了资源获取/释放的固有对称性，如 fopen/fclose，lock/unlock，new/delete。在处理资源时，如果需要通过一对函数获取/释放资源，则可以把该资源封装到一个类中：在构造中获取资源，析构中释放资源。
反面例子
void send(X* x, string_view destination)
{
auto port = open_port(destination);
my_mutex.lock();
// ...
send(port, x);
// ...
my_mutex.unlock();
close_port(port);
delete x;
}
在这个例子中，必须记得在所有路径上调用 unlock、close_port、delete，并且要保证刚好调用一次，并且一旦 ... 部分抛出异常，就会导致资源 x 泄露，my_mutex 也一直是 locked 状态。
正面例子
void send(unique_ptr<X> x, string_view destination)
{
Port port{destination}; // port 拥有 PortHandle
lock_guard<mutex> guard{my_mutex}; // guard 拥有锁
// ...
send(port, x);
// ...
} // 自动 unlock my_mutex 并且 delete x
现在所有资源都是自动释放的，并且保证在所有路径上，无论是否有异常抛出，都只释放一次。不仅如此，这个函数也明确宣布了它对指针 x 的所有权。
Port 只是一个简单的 wrapper，封装了资源：
class Port {
PortHandle port;
public:
Port(string_view destination) : port{open_port(destination)} { }
~Port() { close_port(port); }
operator PortHandle() { return port; }
// port 句柄通常不能复制，如果有必要，禁用拷贝构造和拷贝赋值运算符
Port(const Port&) = delete;
Port& operator=(const Port&) = delete;
};
注
如果资源不是以“具有析构函数的类”的方式呈现，就用类封装一下，或者使用 GSL 库中的 finally ，以便资源能够自动释放
相关惯用法
RAII
R.2: 在接口中，裸指针只用来表示单个对象
换句话说，不要用裸指针表示一个数组。数组最好用容器类型（如：拥有资源的用 vector、不拥有资源的用 span），容器、视图包含大小信息，可以进行边界检查。
反面例子
void f(int* p, int n) // n 是 p[] 元素的数量
{
// ...
p[2] = 7; // bad: 裸指针下标
// ...
}
编译器又不看注释，如果不看其他代码，你无法确定 p 是否真的指向 n 个元素。这种情况最好用 span。
例子
void g(int* p, int fmt) // 用 #fmt 格式打印 *p
{
// ... 仅使用 *p 和 p[0] ...
}
例外
C 风格字符串通过单个指针（指向以 \0 结尾的字符序列）传递，如果你依赖这种约定，最好使用 zstring，而不是 char*
注
很多指向单一元素的指针都可以用引用替代，除非指针可能是 nullptr
代码检查建议
- 如果一个指针不是容器、视图或迭代器，且对该指针进行了算术运算（包括
++），则标记该指针上的算术运算。如果将该规则应用在旧的代码上，可能产生大量误报 - 标记作为简单指针传递的数组
R.3: 裸指针（T*）不拥有资源
在绝大多数的代码中，裸指针都是“非拥有”（non-owning）的，即指针不拥有资源，使用该指针的代码不负责释放指针指向的资源。
我们希望能够标识出“拥有指针”（owning pointer），这样就能安全地释放“拥有指针”指向的资源。
例子
void f()
{
int* p1 = new int{7}; // bad: 裸“拥有指针”，f() 要负责释放 p1 指向的资源
auto p2 = make_unique<int>(7); // OK: unique_ptr 拥有 int
// ...
}
unique_ptr 可以保证及时释放资源，即使发生异常也不会产生泄漏，但是 T* 无法保证。
例子
template<typename T>
class X {
public:
T* p; // bad: 不清楚 p 是否是“拥有指针”
T* q; // bad: 不清楚 q 是否是“拥有指针”
// ...
};
上面的代码无法知道 p、q 是否是“拥有指针”，可以通过下面的方式明确所有权：
template<typename T>
class X2 {
public:
owner<T*> p; // OK: p 是“拥有指针”
T* q; // OK: q 不是“拥有指针”
// ...
};
注
owner<T*> 本质上也是 T*，用 owner<T*> 替代 T* 不会影响 ABI 及原来的代码，它只是用来提示程序员和代码分析工具。如果 owner<T*> 是类的成员，通常应该在类的析构中释放指向的资源。
例外
主要是历史遗留代码，尤其是那些要需要和 C 或者和 C 风格 C++ ABI 兼容。我们不能把所有的“拥有指针”转换成 unique_ptr 或 shared_ptr 来解决这个问题，部分原因是我们在基本的资源管理代码中需要/使用了裸“拥有指针”。例如常见的 vector 实现中，有一个“拥有指针”和两个“非拥有指针”。许多 ABI（以及所有 C 代码接口）都还使用 T*，其中有些是“拥有指针”。有些接口不能简单地用 owner<T*> 标注，因为要和 C 兼容（这个问题可以用宏来解决，只在 C++ 时展开宏，这是宏少有的正确使用场景）。
反面例子
返回裸指针使得调用者无法确切知道该如何进行生命周期管理：调用者是否需要释放指针指向的对象？
Gadget* make_gadget(int n)
{
auto p = new Gadget{n};
// ...
return p;
}
void caller(int n)
{
auto p = make_gadget(n); // 调用者要记得删除 p
// ...
delete p;
}
上述代码除了泄漏问题之外，还可能增加不必要的分配/释放操作。如果 Gadget 很小或者移动成本很低，可以直接按值返回（详见 R.5）：
Gadget make_gadget(int n)
{
Gadget g{n};
// ...
return g;
}
注
本规则适用于工厂方法
注
在必须使用指针的情况下（比如涉及到多态，返回基类指针），返回智能指针
代码检查建议
- 如果 delete 了一个不是
owner<T>的裸指针，给出警告 - 如果没有在所有路径上 reset 或 delete 某个
owner<T>，给出警告 - 如果 new 返回的结果赋给一个裸指针，给出警告
- 如果函数返回了一个在函数内分配的对象，且该对象有移动构造，给出警告，建议考虑按值返回
R.4: 裸引用（T&）不拥有资源
和 R.3 一样，大多数的裸引用也不拥有资源。
例子
void f()
{
int& r = *new int{7}; // bad: 裸“拥有引用”
// ...
delete &r; // bad: 删除裸指针，违反 R.3 规则
}
R.5: 优先使用作用域对象，非必要不在堆上分配
作用域对象（scoped object）可以是局部对象、全局对象或者类成员。除了作用域对象本身，没有额外的分配/释放的开销。作用域对象内部的成员的生命周期由作用域对象的构造/析构管理。
例子
下面代码存在的问题：1. 不必要的分配/释放；2. 如果 ... 部分抛异常，会导致内存泄漏；3. 代码冗长
void f(int n)
{
auto p = new Gadget{n};
// ...
delete p;
}
改用局部对象则可解决上述 3 个问题：
void f(int n)
{
Gadget g{n};
// ...
}
代码检查建议
- 如果一个函数内，某个对象在所有路径上都是先分配，再释放，给出警告。建议用局部栈对象。
- 如果一个局部非 const 的 unique_ptr 或者 shared_ptr 在其生命周期结束之前没有被 move、拷贝、重新赋值或者
reset，给出警告- 例外：如果是一个指向动态数组的局部 unique_ptr，不给出警告，见下面例子：
例外
可以创建一个堆上分配缓冲区的 const unique_ptr<T[]>，这是表示动态数组的合法方式
例子
int get_median_value(const std::list<int>& integers)
{
const auto size = integers.size();
// OK: 声明一个局部 unique_ptr<T[]>.
const auto local_buffer = std::make_unique_for_overwrite<int[]>(size);
std::copy_n(begin(integers), size, local_buffer.get());
std::nth_element(local_buffer.get(), local_buffer.get() + size/2, local_buffer.get() + size);
return local_buffer[size/2];
}
R.6: 避免使用非 const 的全局变量
（同规则 I.2）非 const 的全局变量隐藏了依赖，容易受到无法预测的改变。
例子
struct Data {
// ... lots of stuff ...
} data; // non-const data
void compute() // don't
{
// ... use data ...
}
void output() // don't
{
// ... use data ...
}
你很难知道是否还会有其他地方改变 data
警告
全局对象的初始化顺序不能完全确定，所以只能用常量去初始化全局对象。另外，即使是 const 对象，其初始化顺序也可能是未定义的。
例外
即便是全局对象，一般来说也比单例好
注
-
全局常量是有用的
-
本规则除了适用于“全局变量”外，对命名空间里的变量也适用
替代方案
如果是出于避免拷贝的目的而使用全局变量，可以考虑用 reference to const 来传递数据。或者把该数据作为对象的状态（即类的成员），然后通过成员函数是来操作该成员。
警告
小心数据争用（data race）：如果一个线程可以访问 non-local 数据（或者引用传递的数据），同时另一个线程执行 callee，就可能产生 data race。每个指向可变数据的指针或引用都可能产生数据争用
注
不可变数据（immutable data）不会产生静态条件（race condition）
注
这条规则是“尽量避免”，不是“禁止使用”。会有一些（极少数）例外，比如 cin、cout 和 cerr
代码检查建议
报告所有在命名空间/全局中声明的非 const 变量及指向非 const 对象的指针或引用