C++26：标准库强化

# C++26: 标准库强化 来源：https://www.sandordargo.com/blog/2026/05/13/cpp26-library-hardening C++ 中的未定义行为（UB）是最难处理的 bug 类别之一。它会静默地破坏内存、导致远离实际错误位置的崩溃，或者最糟糕的是——恰好在你的机器上正常工作。在实际代码库中，相当一部分 UB 并非来自于奇特的语言特性，而是源于对标准库的基本误用：越界访问 `vector`、对空容器调用 `front()`，或解引用空的 `optional`。C++26 通过标准库强化直接解决了这个问题，该特性由 P3471R4 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3471r4.html) 引入。 ## 什么是库强化？ 库强化将标准库中的某些未定义行为转化为运行时可检测的契约违反。当强化的前置条件被违反时，运行时会在任何其他可观察副作用发生之前做出反应——可以将其视为为今天属于 UB 的操作添加边界检查。 这并不是一个新想法。三大主流标准库实现已经提供了各自厂商特定的强化模式。问题在于这些机制各不相同、不可移植且规范不一致。P3471R4 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3471r4.html) 将实现已有的做法标准化。标准化的强化版本成为了契约（在 P2900 (https://isocpp.org/files/papers/P2900R6.pdf) 中规定）的首次实际应用。这与语言的发展方向完美契合。 ## 动机：来自实际生产环境的证据 支持此特性的最强论据来自谷歌的生产经验，该提案引用 (https://security.googleblog.com/2024/11/retrofitting-spatial-safety-to-hundreds.html)：在“数亿行 C++ 代码”中应用强化的 libc++ 发现了超过 1000 个 bug，包括安全关键型 bug。平均性能开销低得惊人，仅 **0.30%**——千分之三。这一开销之所以能降低，得益于编译器在优化过程中消除冗余检查的能力。其影响超越了安全性：团队观察到生产环境中**基线段错误率降低了 30%**，这表明代码正确性得到了全面改善。这是多么了不起的成果！ ## 哪些操作会被强化？ 该提案有意识地只关注*内存安全前置条件*。检查所有前置条件是一个“明确非目标”——目标是以低廉的成本捕获高价值的检查。 ### `std::span` - `operator[]`：要求 `idx < size()` - `front()`、`back()`：要求非空 - `first()`、`last()`、`subspan()`：验证 `count` 和 `offset` 在边界内 - 从范围构造的构造函数：验证长度匹配 ### `std::string_view` - `operator[]`：要求 `pos < size()` - `front()`、`back()`：要求非空 - `remove_prefix()`、`remove_suffix()`：要求 `n <= size()` ### 序列容器 (`vector`、`deque`、`list`、`forward_list`、`array`、`string`) - `operator[]`：要求 `n < size()`（对于 `basic_string`，由于访问空终止符是有效的，因此要求 `n <= size()`） - `front()`、`back()`：要求 `!empty()` - `pop_front()`、`pop_back()`：要求 `!empty()` ### `std::optional` 和 `std::expected` - `optional` 上的 `operator->()`、`operator*()`：要求 `has_value()` - `expected` 上的值访问：要求 `has_value()` - `expected` 上的 `error()`：要求 `!has_value()` ### `std::mdspan` - `operator[]`：验证所有多维索引都在其范围内 - 构造函数：验证转换期间的静态范围匹配 ### `std::bitset` 和 `std::valarray` - `operator[]`：要求 `pos < size()` / `n < size()` 有些操作*有意*被排除在外。基于迭代器的操作如 `erase()`、关联容器和算法被推迟——它们需要更复杂的有效性检查，不适合此提案的范围。 ## 具体示例 以下是一些库强化能够捕获的、而今天会静默导致 UB 的示例： ```cpp 1 2 3 4 5 6 std::vector v = {1, 2, 3}; int x = v[5]; // 契约违反：5 >= 3 v.pop_back(); v.pop_back(); v.pop_back(); v.pop_back(); // 契约违反：!empty() 为 false ``` ```cpp 1 2 3 std::string_view sv("hello"); char c = sv[10]; // 契约违反：10 >= 5 sv.remove_prefix(10); // 契约违反：10 > 5 ``` ```cpp 1 2 std::optional opt; int x = *opt; // 契约违反：has_value() 为 false ``` ```cpp 1 2 std::span sp(data, 3); // 契约违反：长度不匹配 sp.first<10>(); // 契约违反：10 > size() ``` 这些都不是难以想象会发生的情况。它们正是那种在代码审查中漏网、只有在生产环境中才会浮现的 bug。 ## 如何激活？ 该提案*不*规定激活机制——这有意留给实现决定。实践中，你可能会看到类似以下形式： - 编译器标志：`-fhardened` 或 `-D_LIBCPP_HARDENING_MODE=...` - 或者实现特定的构建系统选项 一个有意为之的设计选择：在强化实现中，你不能用 `ignore` 语义覆盖强化的前置条件检查。强化的全部意义在于提供一个坚实的安全基线。如果你可以随意关闭个别检查，那么这种保证就毫无意义。此外，由于规定了强化的前置条件违反是一种契约违反，“我们已经越过了 `ignore` 可以绕过检查的节点”。要检查你的编译器是否已经支持强化，可以使用此处列出的各种特性测试宏 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3471r4.html#feature-test-macros)。在撰写本文时，GCC 15 和 MSVC 19.44 已经部分实现了 P3471R4 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3471r4.html)。 ## 结论 库强化是那种让你疑惑为什么没有更早标准化的特性之一。它能以极小的代价捕获真实世界的 bug，而且你无需修改现有代码。三大主流实现多年来一直在做它们自己的版本——C++26 终于使其可移植且一致。如果你在意 C++ 代码中的内存安全性（在 2026 年，你应该在意），那么强化的标准库模式应该成为你构建配置的一部分。 ## 深入链接 如果你喜欢这篇文章，请 - 点击点赞按钮， - 订阅我的通讯 (https://sandor-dargo.kit.com/e19f29b0a1) - 并让我们在 Twitter (https://twitter.com/SandorDargo) 上保持联系！