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 等 。

注

• 见 。

  • 静态检查工具 。

  • 并发工具 。

  • 测试工具 。

• 还有许多其他类型的工具，如代码仓库、构建工具等，这些不在 C++ 核心指南范围内 。

• 不要依赖过于复杂、特殊的工具链，这会让可移植代码变得不可移植 。

P.13：根据需要使用支持库

使用设计/文档/支持良好的库可以节省时间和精力。无论是代码质量还是文档质量，通常要比自己写的好得多。库的开发维护成本是被所有用户平摊的（实际上大多数优秀的库都是可以免费使用的）。如果一个库有很多用户，也更容易保持更新并移植到新系统，并且相关的使用经验和知识也可以在其他项目复用，节约时间和精力.

例子

                        
                          std::sort(begin(v), end(v), std::greater<>());

                        
                      

除非你是排序算法的专家，并且有大量时间，否则你很难写出比上面那一行更正确、更快的排序代码.

使用标准库（或其他基础库）不需要理由；相反，不用标准库最好给出充分的理由.

注

• 默认使用 C++ 标准库、GSL
  • ISO C++ Standard Library
  • Guidelines Support Library
• 如果在某个重要领域，尚无设计/文档/支持良好的库，或许你需要设计并实现一个

最后此篇关于C++核心指南之C++哲学/基本理念（下）的文章就讲到这里了,如果你想了解更多关于C++核心指南之C++哲学/基本理念（下）的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。