C++26：标准库强化实验

“强化”似乎是 2026 年 C++ 世界中非常流行的术语。在本文中，我们将探讨这个词的含义并查看一些核心示例。强化的库能让 C++ 完全安全吗？让我们来看看吧。核心思想 当您了解 std::vector 时，您可能还记得您可以使用至少两个表达式来访问第 i 个位置的元素： std::vector < int > v { 1 , 2 , 3 , 4 }; v[i]=10； // 对于某些 i v 。在 ( j ) = 11 ; // 对于某些 j 这两者之间的主要区别在于 [] 是未经检查的（如果您尝试访问不存在的元素，则可能会生成未定义的行为），而 .at() 可能会抛出 std::out_of_range （因此这是一个明确定义的行为）。 C++26 更改 在 C++26 中，标准引入了强化实现的概念。标准库实现是否强化以及如何启用该模式是由实现定义的。对于 std::vector::operator[](size_type pos) ：C++ 标准条件，直到 C++26 如果 pos < size() 为 false ，则行为未定义。自 C++26 起 如果 pos < size() 为 false ：如果实现经过强化，则会发生契约违规；如果实现未经过强化，则行为未定义。换句话说，如果您切换这种“强化”模式，您将得到一些明确指定的错误/违规，而不仅仅是未定义的行为。让我们理清措辞和常见问题：对于 .at() 你可能会遇到异常……那么为什么我们需要一个新的替代方案呢？这是一个公平的问题。简而言之，at() 和 [] 具有不同的接口和性能/错误处理方法。更重要的是你不能轻易地关闭异常（你可以，并且 std::terminate 将会被调用，但这不是很灵活）。因此，强化不会将operator[]更改为at()——它会检测到编程错误并终止，而不是允许内存不安全的未定义行为。 “发生了合同违规”——这是这里的关键。 “强化”功能以合同的形式表达，这些合同也被 C++26 接受。 C++26 使用新的契约模型指定了强化的前提条件：在强化的实现中违反一个前提条件会导致使用终止语义来评估契约违规。但是，库实现不一定使用实际的 pre 、 post 或contract_assert 语言语法来实现这些检查。那么这个合同违约是什么呢？普通 C++26 契约可以使用忽略、观察、强制或快速强制语义。强化标准库前提条件更具限制性：在强化实现中，它们必须使用终止语义，因此在检查失败后无法继续执行。它的实现取决于如何在这些模式之间切换。在此处阅读更多内容：合约断言 (C++26 起) - cppreference.com 它在运行时有效吗？是的，实际上它可以在常量表达式中运行，但更重要的是，它在运行时运行。这与 GLIBCXX_ASSERTIONS 、 _ITERATOR_DEBUG_LEVEL 等有什么关系？ C++26 尝试引入这些供应商特定的检查器并创建一组通用的、定义良好的规则。主要问题：如何启用这个东西？ GCC / libstdc++：_GLIBCXX_ASSERTIONS 支持轻量级标准库前提条件检查。 GCC 更广泛的 -fhardened 选项使其能够自动与其他安全选项一起使用。 Clang / libc++：使用 _LIBCPP_HARDENING_MODE ，具有 NONE 、 FAST 、 EXTENSIVE 和 DEBUG 模式。 MSVC STL：_MSVC_STL_HARDENING=1 启用全局强化。可以使用 _MSVC_STL_HARDENING_VECTOR 和 _MSVC_STL_HARDENING_OPTIONAL 等宏来控制各个类型。注意：在撰写本文时（2026 年 8 月），编译器和库供应商仍在完成 C++26 功能。以下选项是当前供应商强化机制，并不一定代表 P3471/P3697/P3878 的完整实现 核心文档和建议 我们有以下论文构成了从 C++26 开始的整个功能： P3471 - 主要标准库强化 P3697 - C++26 标准库强化的少量补充 - basic_stacktrace、shared_ptr、view_interface（正面、背面）、 counted_iterator、common_iterator P3878 - 标准库强化应使用终止语义。确保不能简单地观察到硬化前提条件违规，然后继续进入硬化旨在防止的 UB。强化模式 — libc++ 文档 为了在标准中指定强化，本提案引入了强化前提条件的概念。强化前提条件是在强化实施中导致合同违规的前提条件。向库添加强化主要包括将一些现有前提条件转变为规范中强化的前提条件。候选者需要什么条件才能获得强化实施？违反前提条件会导致内存安全问题（越界访问或访问未初始化的内存）；呼叫站点拥有所有必需的