21CTO 导读：不必换到Rust，使用C++的Profiles配置文件机制，就可以让代码变得安全。

美国国家安全局（NSA）发布了一份网络安全信息表， 强调了内存安全的重要性，并建议从内存不安全的编程语言，例如C和C++，转向内存安全的语言，例如Rust。

C++的创始人 Bjarne Stroustrup博士对此进行了回应，引起了技术圈不小的轰动。

在CppCon 2026 的开幕演讲《Profiles for simplicity and guarantees》上， Bjarne Stroustrup向人们给出的解决方案叫做 Profiles——称为配置文件，即不换语言、不重写、零运行时开销。

他说之前是做到的，以下是开源后的实际东西。

GitHub：https://github.com/BjarneStroustrup/profiles

他的PPT描述请见如下图所示。

Profiles 到底是什么

Profiles 本质是一套带命名、可由编译器强制校验的规则集合。开发者可以为单个编译单元绑定指定 profile，编译器就会在编译阶段拦截各类已知的未定义行为：未初始化变量读取、数组越界访问、容器迭代器失效等问题。整套机制不会新增运行时检查逻辑，也不需要垃圾回收，现有代码甚至不用改动一行。

这套底层思路被称作 “超集的子集”：先用更安全的标准库扩展语言能力（超集），再依靠静态分析剔除危险写法（子集），代码表达能力与运行性能完全不受影响。 这并不是停留在理论层面的构想，WebKit 就依靠同类思路加固了超 400 万行 C++ 代码；而 Profiles，正是把这套成熟工程实践推向 C++ 标准。

一句话概括核心机制：按编译单元绑定规则，编译器静态校验，零运行开销。

演讲中展示了两大典型场景：Initialization 规则拦截未初始化对象读取；Invalidation 规则杜绝容器失效引发的悬垂指针 —— 比如 vector 扩容后旧迭代器失效这类经典 bug，编译器可以在编译期直接捕获，全程不会产生任何运行时损耗。

一句话总结机制：按翻译单元签约，编译器静态强制，零运行时开销。

在他的演讲里演示了两个实例：Initialization 消灭未初始化对象读取；Invalidation 消灭容器失效类悬垂指针——vector 扩容后旧迭代器全部失效，这类 bug 编译器现在能静态抓住。两者运行时成本均为零。

看清时间表

提案链很完整：P3274（框架）、P3446（Invalidation）、P4222R1（Initialization，2026 定案）、P3984（[[profiles::enforce]] 强制属性）。但注意：enforce 的目标是 C++29，不是 C++26。C++26 已经交付的是地基——hardened 标准库、未初始化局部变量从 UB 变为确定性行为、contracts 前后置断言。

三个判断

业内对于 C++ Profiles 的发展前景，形成了三个核心观点：

第一，Profiles 真正的竞争对手并不是 Rust，而是海量无法整体迁移的存量代码，规模可达数十亿行。语言迁移方案只适合新项目；汽车、航空、金融交易这类重资产系统，整体重构只会带来巨大风险。以模块为单位，分批绑定 profile，才是现实可行的路径。

第二，优先落地窄范围安全保证，远好于空泛的宏大承诺。优先搞定初始化、迭代器失效这类可以静态验证的场景，远比宣称实现 “绝对内存安全” 更加务实可信。

第三，虽然enforce特性要等到 C++29，但现在就可以动手实践：升级 GCC16 或者新版 MSVC，开启 C++26 模式，使用
契约断言，提前借助编译器约束代码规范。

抛弃那些“巧妙”代码

“我通常改进方法的做法是，先把那些花哨的东西扔掉，然后看看速度是变快了还是变慢了。通常情况下，速度都会变快。”

Stroustrup多年来一直在重复类似的说法。他的核心论点是，现代编译器能够处理更多数据，进行更严格的优化，而上世纪90年代手工调优的代码，如今在硬件上性能会大打折扣，因为这些硬件的分支预测器和缓存层次结构并非当初设计时所考虑的。

那么问题来了：如果编译器能替你保证一类安全，你愿意将项目"签约"入驻 profile 么？

作者：手扶拖拉斯基

参考：

千文部落 https://mp.weixin.qq.com/s/7Dk0lnKED6bK6MGsOjBGXQ?scene=1

HFT University https://hftuniversity.com/post/stroustrup-says-throw-away-the-clever-code-we-measured-four-hft-kernels