C++ 核心指南之 C++ P.哲学/基本理念（上）

来源：cnblogs　　作者：Zijian/TENG　　时间：2023/7/31 9:11:21　　对本文有异议

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<string>& v)
{
    string val;
    cin >> val;
    int index = -1; // ?? 而且应该用 gsl::index
    for (int i = 0; i < v.size(); ++i) {
        if (v[i] == val) {
            index = i;
            break;
        }
    }
}

实现同样功能，用标准库则可以更清晰地表达意图

void f(vector<string>& 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++ 的。

有的环境下需要扩展，如访问系统资源。这种情况下应该限制扩展的使用范围。如果可以，用接口封装扩展，以便在不支持扩展特性的系统上关闭或屏蔽这部分代码
（标准中没有规定的）扩展通常没有严格的定义，即使是那些常见的、被大多数编译器支持的扩展特性（如 #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 中元素的顺序的意图。

程序员应该熟悉：

GSL
C++ 标准库
当前项目使用的基础库

注

说明要做什么，而不是怎么做
有些编程语言在表达意图方面比其他语言做得更好

例子

如果用 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<T>)
作用域很大的循环控制变量
裸的 new 和 delete
参数过多的函数

有工具可以（半）自动检测并给出修改建议（如 clangd）

P.4：（理想情况下）程序应该是静态类型安全的

理想强况下，编译器在编译过程中可以进行静态类型检查，程序应该是（编译期）类型安全的。实际上是不可能的，因为：

unions
类型转换
数组退化
范围错误
窄化转换

注

上述几点也是严重问题的根源（如程序崩溃、安全漏洞）。C++ 在尝试用一些替代技术来规避上述问题

代码检查建议

union ?? C++ 17 variant
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