C++ 核心指南之 C++ 哲学/基本理念(下)
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.7:尽早捕获运行时错误
- P.8:不要泄露任何资源
- P.9:不要浪费时间或空间
- P.10:优先使用不可变数据而不是可变数据
- P.11:封装混乱的结构,而不是让其散布在代码中
- P.12:根据需要使用支持工具
- P.13:根据需要使用支持库
这些基本理念是其他章节具体规则的理论基础。
P.7:尽早捕获运行时错误
以避免(可能无法发现的)错误结果或莫名其妙地程序崩溃
例子
// 👎 容易出错
void increment1(int* p, int n)
{
for (int i = 0; i < n; ++i) ++p[i];
}
void use1(int m)
{
const int n = 10;
int a[n] = {};
// 可能是手误,或者 m<=n,但万一 m==20 ...
increment1(a, m);
}
use1()
中犯了个小错误,可能导致数据损坏或程序崩溃。形如 f(pointer, count)
这样形式的接口没有办法彻底避免 “out-of-range” 错误。如果我们检查下标越界,那也要等到访问 p[10]
的时候才能发现。可以改进代码,更早地进行检查:
void increment2(span<int> p)
{
for (int& x : p) ++x;
}
void use2(int m)
{
const int n = 10;
int a[n] = {};
// 可能是手误,或者 m<=n
increment2({a, m});
}
现在 m <= n
能在调用 increment2()
时就检查。如果本来就想用 n
作为边界,代码可以进一步简化(同时也消除了错误的可能):
void use3(int m)
{
const int n = 10;
int a[n] = {};
// 不需要重复元素个数
increment2(a);
}
反面例子
不要重复检查同一个值,不要把结构化的数据作为 string 传递:
// 从 istream 中读日期
Date read_date(istream& is);
// 从 string 中提取日期
Date extract_date(const string& s);
// 操作日期
void user1(const string& date)
{
auto d = extract_date(date);
// ...
}
void user2()
{
Date d = read_date(cin);
user1(d.to_string());
}
user2() 中同一个日期被 Date 的构造函数校验了 2 次(一次在调用 read_date() 时,一次在调用 user1() -> extract_date() 时),并且原本结构化的 Date d
作为(非结构化的) string 传给了 user1()
注
额外的检查是有开销的。有时过早的检查效率不高,因为可能根本用不到这个值。或者只用到了部分,而只检查整个值的开销远大于检查用到部分的开销。类似地,不要增加改变接口复杂度的检查,例如不要在一个平均复杂度 O(1) 的接口中添加一个 O(n) 的检查。
代码检查建议
- 检查指针和数组:尽早进行范围检查,但不要重复检查
- 检查转换:标记或消除窄化转换
- 查找没有进行检查的输入值
- 查找被转为 string 的结构化数据(含有不变量的类)
- ...
P.8:不要泄露任何资源
即便资源消耗以极其缓慢的速度增加,最终也会耗尽资源,尤其是对长时间运行的程序来说。
反面例子
void f(char* name)
{
FILE* input = fopen(name, "r");
// 👎 如果 something == true,文件句柄泄漏
if (something) return;
// ...
fclose(input);
}
应该使用 RAII:
void f(char* name)
{
ifstream input {name};
// OK:不会泄露
if (something) return;
// ...
}
参见:资源管理 R 篇
注
“泄漏”是指资源没有清理或者再也无法被清理。例如,在堆上分配一个对象,然后丢弃指向该对象的指针。
- 本规则不要求在程序结束时回收 long-lived 对象。例如,操作系统能够保证在进程结束时自动清理打开的文件、分配的内存,依赖操作系统的该机制可以简化代码。但是依赖隐式清理的抽象更简单,也更安全
- 强制实施生命周期安全 Profile 可以消除泄漏。结合 RAII 提供的资源安全性,可以消除对“垃圾回收”的需求,因为根本不会产生垃圾。再结合 类型和边界 Profiles 可以做到完全的类型&资源安全(由工具保证)
代码检查建议
- 检查指针:参见:资源管理 R 篇,把指针划分为“拥有指针”和“非拥有指针(默认)”。如果可以,用标准库的资源管理(如上面的例子)。或者把拥有指针用 GSL 库中的 owner 标记
- 查找裸的
new
和delete
- 查找返回裸指针的资源分配函数(如
fopen
,malloc
,strdup
)
P.9:不要浪费时间或空间
注
因为这是 C++。但如果花费的时间和空间是为了达成特定目标(例如开发速度,资源安全或简化测试),那么并不算浪费。
“追求效率的另一个好处是,这个过程会迫使你更深入地理解问题。” —— Alex Stepanov
反面例子
struct X {
char ch;
int i;
string s;
char ch2;
X& operator=(const X& a);
X(const X&);
};
X waste(const char* p)
{
if (!p) throw Nullptr_error{};
int n = strlen(p);
auto buf = new char[n];
if (!buf) throw Allocation_error{};
for (int i = 0; i < n; ++i) buf[i] = p[i];
// ... 操作 buffer ...
X x;
x.ch = 'a';
// give x.s space for *p
x.s = string(n);
// copy buf into x.s
for (gsl::index i = 0; i < x.s.size(); ++i)
x.s[i] = buf[i];
delete[] buf;
return x;
}
void driver()
{
X x = waste("Typical argument");
// ...
}
这是一个夸张的例子,但每一个错误(甚至更糟的)都在实际生产代码中出现过。结构体 X 的布局至少浪费了 6 个字节。显式声明的拷贝构造和拷贝赋值运算符抑制了移动操作,导致返回操作较慢(注意:这里不能保证 RVO 返回值优化)。对 buf
使用 new
和 delete
是多余的;如果真的需要一个局部字符串,应该使用局部 string
。还有几处代码,完全没有必要实现得那么复杂。
反面例子
void lower(zstring s)
{
for (int i = 0; i < strlen(s); ++i) s[i] = tolower(s[i]);
}
这是一个真实生产代码的例子。在循环中的条件是 i < strlen(s)
。这个表达式在每次循环迭代时都会被计算,这意味着 strlen
必须在每次循环中遍历字符串来计算字符串长度。虽然字符串内容改变了,但 tolower
不会影响字符串的长度,所以最好在循环之外缓存字符串长度,而不是每次循环都重新计算长度。
注
一个浪费的例子并不会产生显著的影响,如果影响显著,通常可以轻易地发现并消除。但如果代码库中到处都是这样的代码,则很容易从量变到质变。这个规则的目的是在问题出现之前,消除 C++ 使用相关的大部分浪费。之后,我们可以考虑与算法和需求相关的浪费,但这超出了 C++ 核心指南的范围。
代码检查建议
有许多更具体的规则,旨在实现“简单,消除不必要浪费”这个整体目标。
- 标记后置递增/递减运算符
operator++()
或operator--()
未使用的返回值,最好使用前置形式
P.10:优先使用不可变数据
- 不可变数据不会意外地改变
- 更容易优化
- 不会产生数据竞争(data race)
见条款 Con: Constants and immutability
P.11:封装混乱的结构,而不是让其散布在代码中
- 混乱的代码容易藏着 bug
- 好的接口更容易使用,也更安全
- 混乱、低级的代码更容易产生更多混乱的代码(破窗理论)
这里的低级(low-level)指的是代码的抽象层级较低,直接操作指针、malloc、realloc 等这样的低层函数
例子
int sz = 100;
int* p = (int*) malloc(sizeof(int) * sz);
int count = 0;
for (;;) {
// ... read an int into x, exit loop if end of file is reached ...
// ... check that x is valid ...
if (count == sz)
p = (int*) realloc(p, sizeof(int) * sz * 2);
p[count++] = x;
// ...
}
这是一段低级、冗长、易错的代码:例如这里就没有考虑内存耗尽的问题。应该使用 vector:
vector<int> v;
v.reserve(100);
// ...
for (int x; cin >> x; ) {
// ... check that x is valid ...
v.push_back(x);
}
注
标准库和 GSL 是该思想的体现:vector、span、lock_guard、future 等关键抽象封装了低层的数组、union、类型转换等操作。通常库的设计/实现者远比我们更专业,花的时间也更多。我们应该使用库提供的高级抽象,而不是让低层细节搞乱我们的代码。
代码检查建议
查找混乱的代码,例如
- 复杂的指针操作
- casting outside the implementation of abstractions
P.12:根据需要使用支持工具
有的事情让机器来做更合适:计算机不会对重复的工作感到无聊和厌倦,而人类可以做一些更有价值的事情
例子
运行静态代码分析工具来确保代码遵循某些规范:如 coverity、clang-tidy、clang-format 等
注
P.13:根据需要使用支持库
使用设计/文档/支持良好的库可以节省时间和精力。无论是代码质量还是文档质量,通常要比自己写的好得多。库的开发维护成本是被所有用户平摊的(实际上大多数优秀的库都是可以免费使用的)。如果一个库有很多用户,也更容易保持更新并移植到新系统,并且相关的使用经验和知识也可以在其他项目复用,节约时间和精力。
例子
std::sort(begin(v), end(v), std::greater<>());
除非你是排序算法的专家,并且有大量时间,否则你很难写出比上面那一行更正确、更快的排序代码。
使用标准库(或其他基础库)不需要理由;相反,不用标准库最好给出充分的理由。
注
- 默认使用 C++ 标准库、GSL
- 如果在某个重要领域,尚无设计/文档/支持良好的库,或许你需要设计并实现一个