C++ 核心指南（C++ Core Guidelines）是由 Bjarne Stroustrup、Herb Sutter 等顶尖 C+ 专家创建的一份 C++ 指南、规则及最佳实践。旨在帮助大家正确、高效地使用“现代 C++”。
这份指南侧重于接口、资源管理、内存管理、并发等 High-level 主题。遵循这些规则可以最大程度地保证静态类型安全，避免资源泄露及常见的错误，使得程序运行得更快、更好。
文中提到的 GSL(Guidelines Support Library) 是 C++ 核心指南支持库 https://github.com/Microsoft/GSL
P：Philosophy 基本理念
本节的规则反映了现代 C++ 的哲学/基本理念，贯穿整个 C++ 核心指南：
规则摘要：
- P.1：直接用代码表达想法
- P.2：编写符合 ISO 标准的 C++ 代码
- P.3：表达意图
- P.4：（理想情况下）程序应该是静态类型安全的
- P.5：优先使用编译时检查而不是运行时检查
- P.6：无法在编译时检查的内容应该在运行时可检查
- P.7：尽早捕获运行时错误
- P.8：不要泄露任何资源
- P.9：不要浪费时间或空间
- P.10：优先使用不可变数据而不是可变数据
- P.11：封装混乱的结构，而不是让其散布在代码中
- P.12：根据需要使用支持工具
- P.13：根据需要使用支持库
这些基本理念是其他章节具体规则的理论基础。
P.1：直接用代码表达想法
关联 P.3
- 代码不会说谎，注释可不一定
- 编译器不看注释（很多程序员也不看 🙈）
- 代码有确定性的语义，编译器和工具可以帮助检查
例子
class Date {
public:
Month month() const; // 👍
int month(); // 👎
};
第一个 month() 明确地声明返回 Month 对象，并且不会修改 Data 对象的状态
第二个 month() 只能让读者去猜，也更容易产生 bug
例子
直接使用语言特性，代码冗长，且不能直接表达意图
void f(vector& v)
{
string val;
cin >> val;
// 👎 而且应该用 gsl::index 作为索引类型
int index = -1;
for (int i = 0; i < v.size(); ++i) {
if (v[i] == val) {
index = i;
break;
}
}
}
实现同样功能，用标准库则可以更清晰地表达意图（要做什么，而不是怎么做）
void f(vector& v)
{
string val;
cin >> val;
auto p = find(begin(v), end(v), val); // better
}
开发者应该熟悉 C++ 标准库以及项目的基础库。如果使用 C++ 核心指南，还应该知道 GSL（Guidelines Support Library），并且在适当的时候使用。
例子
// 👎 s 是代表什么？
change_speed(double s);
change_speed(2.3);
更好的做法是明确 double 的含义（绝对速度？变化值？）以及使用的单位：
change_speed(Speed s); // 稍好一些，s 代表速度绝对值
change_speed(2.3); // 错误：没有单位
change_speed(23_m / 10s); // 单位 m/s
也可以用不带单位的 double 作为速度变化值，但这样容易出错。更好的做法是定义 Delta 类型。
代码检查建议
-
如果不修改对象/参数，使用 const 明确地表达意图
- 检查成员函数是否修改对象状态
- 检查函数是否修改传入的指针或引用参数
-
警惕强制类型转换，强制类型转换使得编译器无法帮你进行类型检查。一般来说，强制类型转换意味着程序设计的缺陷
-
检查和标准库行为类似的代码：例如很多循环都可以用标准库算法替代
P.2：编写符合 ISO 标准的 C++ 代码
这份指南是针对 ISO 标准 C++ 的。
-
有时需要在 ISO 标准之外进行扩展，如访问系统资源。这种情况下应该限制扩展的使用范围。如果可以，用接口封装扩展，以便在不支持扩展特性的系统上关闭或屏蔽这部分代码
-
（标准中没有规定的）扩展通常没有严格的定义，即使是那些常见的、被大多数编译器支持的扩展特性（如
#pragma once），在某些边界条件下，行为可能会有微小差异。 -
扩展会影响代码可移植性；但完全遵守 ISO 标准并不能保证可移植性
-
避免未定义的行为，如表达式的求值顺序
int i = foo() * bar();其中 foo() 和 bar() 的调用顺序未定义！- 参考 undefined order of evaluation
-
理解“取决于实现”的含义。例如 C++ 标准只规定了 int 类型的最小大小，并没有规定确切的大小，不同的 C++ 实现可以采用不同的大小
-
有的环境需要限制使用某些 C++ 标准库和特性，如汽车、航空领域中的禁用动态内存分配、异常机制等
代码检查建议
使用最新的 C++ 编译器，在编译选项中关闭扩展特性
P.3：表达意图
关联 P.1
除非通过命名或者注释表达了某些代码的意图，否则很难判断代码是否在做该做的事
例子
gsl::index i = 0;
while (i < v.size()) {
// ... do something with v[i] ...
}
上述代码中，遍历 v 中元素的意图没有很好地表达出来。下标索引 i 对外暴露，且生命周期超出循环体，存在被误用的可能性。更好的做法：
for (const auto& x : v) { /* do something with the value of x */ }
改进后的代码不涉及具体迭代机制（如下标索引），并且循环操作的是一个 const 引用，不会意外地修改 v 中数据。如果的确需要修改，可以改为非 const 引用：
for (auto& x : v) { /* 修改 x */ }
关于 for 语句详见条款 ES.71。更好的做法是用使用标准库的算法，例如 for_each，可以直接地表达意图：
for_each(v, [](int x) { /* do something with the value of x */ });
for_each(par, v, [](int x) { /* do something with the value of x */ });
这个版本还传达了我们不关心处理 v 中元素的顺序的意图。
程序员应该熟悉：
注
- 说明要做什么，而不是怎么做
- 有些编程语言在表达意图方面比其他语言做得更好
例子
如果用 2 个 int 表示一个点的二维坐标：
// 不明确，需要查文档
// (x1,y1,x2,y2) 还是 (x,y,h,w)？
draw_line(int, int, int, int);
// 更清晰
draw_line(Point, Point);
代码检查建议
有些常见的模式有更好的替代方案：
- 简单的 for 循环 ➡️ 范围 for 循环
f(T*, int)接口 ➡️f(span) - 作用域很大的循环控制变量
- 裸的 new 和 delete
- 参数过多的函数
有工具可以（半）自动检测这些问题并给出修改建议（如 clangd）
P.4：（理想情况下）程序应该是静态类型安全的
理想情况下，编译器在编译过程中可以进行类型检查，程序应该是静态（编译期）类型安全的。实际上不能完全做到，因为：
- unions
- 类型转换
- 数组退化（数组作为形参时退化为指针）
- 范围错误
- 窄化转换
注
这些领域也是高危问题（如程序崩溃、安全漏洞）的最大根源。C++ 在尝试用一些替代技术来规避上述问题
代码检查建议
- union ➡️ variant (C++ 17)
- cast ➡️ 尽量避免使用，模版可以解决一部分问题
- 数组退化 ➡️ 使用 span（GSL）
- 范围错误 ➡️ 使用 span
- 窄化转换 ➡️ 尽量避免使用，如果必要可以使用 GSL 中的 narrow 或者 narrow_cast
P.5：优先使用编译期检查而不是运行期检查
不需要针对运行期错误编写错误处理代码，代码更清晰，性能也更好。
例子
// Int 是整数类型别名
// 👎 运行期检查
int bits = 0;
for (Int i = 1; i; i <<= 1)
++bits;
if (bits < 32)
cerr << "Int too small\n";
这段代码并没有达到它想要达到的目的，因为 C++ 标准没有规定溢出的行为。即溢出的行为是未定义的，不同平台、不同编译器的行为可能并不相同！
应该用更简单的 static_assert 来替代：
// Int 是整数类型别名
// OK：编译期检查
static_assert(sizeof(Int) >= 4);
更好的做法是直接用 int32_t
例子
// 读取最多 n 个整数到 *p
void read(int* p, int n);
int a[100];
read(a, 1000); // 👎 越界
更好的做法：
// 读到一个 span 中
void read(span<int> r);
int a[100];
read(a); // better: 让编译器自动计算元素数量
总之，不要把编译期能做的事推迟到运行时！
代码检查建议
- 检查函数参数中是否有指针
- 检查代码中是否有运行时的范围检查
P.6：无法在编译时检查的内容应该在运行时可检查
理想情况下，应该捕获所有错误，要么在编译期，要么在运行时。实际上不可能在编译期捕获所有的错误，想在运行期捕获所有剩余的错误也很困难。但是我们还是要尽量去编写可检查的代码，否则可能导致错误的结果或者程序崩溃。
反面例子
// 独立编译，可能动态加载
extern void f(int* p);
void g(int n)
{
// 👎 元素数量没传给 f
f(new int[n]);
}
这里元素的数量这一关键信息没有传递给 f，并且这种情况静态代码分析工具可能无法检测，即使动态检查可能也会非常困难。特别是当 f() 是 ABI 的一部分时，我们无法去“检视”指针参数。这样的设计让程序很难检测错误。
反面例子
当然，可以把元素数量和指针一起传递
// 独立编译，可能动态加载
extern void f2(int* p, int n);
void g2(int n)
{
// 👎 还是会有传错 m 的可能
f2(new int[n], m);
}
这是一种很常见的做法：把元素数量作为单独的参数传递，这比只传指针、然后通过其他（没有明确说明的）途径获取元素数量要好一些。但即便如此，一个小的手误（如把 n 按成 m）就可能导致严重的问题。并且 f2() 的两个参数之间的联系只是一种约定，但不够明确。
此外，f2() 应该 delete[] 参数这一点也没有明确说明（或者本该由 f2() 的调用者负责 delete[] 但是忘记了？）
反面例子
标准库的智能指针并不能传递元素的数量：
// 独立编译，可能动态加载
// 假设调用代码和标准库是 ABI 兼容的，用兼容的 C++编译器编译
extern void f3(unique_ptr<int[]>, int n);
void g3(int n)
{
// 👎 分开传递指针和大小
f3(make_unique<int[]>(n), m);
}
正面例子
把指针和元素的数量作为一个整体传递：
// 独立编译，可能动态加载
// 假设调用代码和标准库是 ABI 兼容的，用兼容的 C++编译器编译
extern void f4(vector<int>&);
extern void f4(span<int>);
void g3(int n)
{
vector<int> v(n);
f4(v); // 传引用，调用者拥有所有权
f4(span<int>{v}); // 传视图，调用者拥有所有权
}
元素数量是对象的一部分，不容易出错，且总是可以在运行时检查。
例子
如何同时传递所有权和校验所需的全部信息？
// OK: 移动 vector
vector<int> f5(int n)
{
vector<int> v(n);
// ... initialize v ...
return v;
}
// 👎 丢失大小信息 n
unique_ptr<int[]> f6(int n)
{
auto p = make_unique<int[]>(n);
// ... initialize *p ...
return p;
}
// 👎 丢失大小信息 n，并且用完可能忘记删除
owner<int*> f7(int n)
{
owner<int*> p = new int[n];
// ... initialize *p ...
return p;
}
例子
- TODO：需要增加一个例子
- show how possible checks are avoided by interfaces that pass polymorphic base classes around, when they actually know what they need? Or strings as “free-style” options
代码检查建议
- 标记 (指针，数量) 这种接口（可能会有很多因为兼容性原因无法修复）
- ...