2024 年 11 月，WG21 在波兰弗罗茨瓦夫召开会议。距离 C++26 冻结功能只剩一次会议，一份名为 P2900 的提案成为全场焦点。它试图回答一个问题：C++ 能不能在不改变语言本质的前提下，获得类似 Rust 的内存安全保证？
什么是 Profiles
P2900 的核心概念叫 Profiles（配置文件）。简单说，它是一套可选的安全规则集合，由编译器或静态分析工具执行。
具体来说，Profiles 会做三件事：
- 禁用危险构造：比如
reinterpret_cast、野指针运算等。
- 注入运行时检查：数组越界、整数溢出、未初始化读取等会被自动检测。
- 生命周期追踪：通过类似
-Wlifetime 的静态分析，在编译阶段捕获悬空指针和释放后使用。
// 在 Profile 模式下，这段代码可能被拒绝编译
int* p = new int[10];
int x = p[20]; // 越界访问：运行时抛异常或编译报错
delete[] p;
int y = *p; // 释放后使用：静态分析警告
这套机制是可选的。你可以给项目开启 bounds profile、type profile 或 lifetime profile，也可以一个都不用。旧代码不需要任何修改，不用加 unsafe 关键字，也不用重写标准库。
与 Rust 的本质区别
很多人把 Profiles 和 Rust 的安全模型放在一起对比，但两者差距很大。
Rust 的安全是强制性的。编译器通过借用检查和所有权系统，在编译阶段就证明代码没有内存安全漏洞。这是一套完整的、数学上严格的理论。
P2900 的 Profiles 则是修复性的。它不改变 C++ 的类型系统，不引入所有权或借用检查，而是在现有语法上叠加一层检查和运行时保护。打个粗略的比方：Rust 是在渠道入口加罚单，P2900 是在渠道中游加了栏杆。
这种设计有明确考量：C++ 有数百亿行存量代码，任何需要大规模重写的方案都难以落地。Profiles 的目标是让现有项目能够逐步采用安全措施，而不是逼迫开发者放弃现有代码。
为什么现在推进
这不是技术自发产生的需求，而是外部压力的结果。美国和欧盟将内存不安全视为国家安全威胁，C 和 C++ 因历史上的缓冲区溢出、野指针等问题被列入"调查清单"。从操作系统内核到浏览器引擎，政府都在要求使用"内存安全语言"。
C++ 标准委员会的回应很直接：需要在 C++26 中提供一套官方安全方案，否则市场可能被 Rust 吃掉。Profiles 的目标就是在 C++26 中落地。
争议与质疑
但 Profiles 在委员会内部引发了巨大争议。
静态分析的局限性。多年实践证明，在不修改语言的情况下，仅靠静态分析实现绝对内存安全并不现实。-Wlifetime 项目自 2018 年提出以来，至今仍未达到可部署状态。如果这条路真的走得通，为什么没有主要编译器厂商大量投入？
假阳性问题。安全检查不可避免会产生误报。开发者对警告的容忍度几乎为零——几个假阳性警告之后，整个检查就会被关掉。如果 Profiles 的误报率高，实际价值就会大打折扣。
与 "Safe C++" 的竞争。Sean Baxter 提出的借用检查方案是目前唯一被数学证明有效的内存安全解决方案。但它需要大规模重写标准库，实际上更像是一门继承者语言。
时间线太紧。P2900 试图在 C++26 冻结之前落地，但大量细节仍未明确。有人质疑：连规则都没有完整实现的提案，为什么要写进国际标准？
对 C++ 开发者意味着什么
对大多数开发者来说，Profiles 的影响分三层：
- 无感层：不开启任何 Profile，代码和以前完全一样。
- 可用层：开启
bounds 或 initialization profile，获得运行时保护，但可能要付出性能代价。
- 库作者：维护广泛使用的库时，需要考虑在哪些场景下兼容 Profiles，否则用户开启安全检查时可能遇到问题。
不管 Profiles 最终是否进入 C++26，它标志着一个转折点：C++ 社区已经意识到，内存安全不再是可选课题，而是生存必需品。问题只是，我们愿意为它付出多少代价。关于 P2900 的后续进展，云栈社区 也会持续关注。
发表于 14 小时前
|
查看: 6|
回复: 0
