C++ 创始人反驳白宫警告

C++ 安全性 vs 指南

• 许多人认为 C++ 从根本上仍然不安全：安全“指南”只是可选的、执行不均，而且很难套用到现有代码上。
• 也有人认为，只要严格自律，C++ 可以“足够安全”：限制特性子集、使用智能指针、值语义、sanitizers、最大化警告级别，以及与核心指南对齐的 lint 工具。
• 一些人指出，更现代的特性（例如 string_view、迭代器）本身就很容易被误用，并可能引入微妙的生命周期 bug。

性能争论（C++ vs 其他语言）

• 一方声称，现代 Java 和其他托管语言在“真实世界”性能上经常与 C++ 持平甚至更好，尤其是典型 C++ 项目缺乏先进的构建/优化配置（PGO、LTO 等）时。
• 反对者则回应，在高性能领域（AI/ML、HPC、GPU 工作负载）几乎都依赖 C/C++，而 Java/GC 约束使其不适合这些极端场景。
• 还有人强调，C++ 只有在专家积极管理内存布局、分配和缓存行为时才会稳定胜出——这类努力大多数代码库都做不到。

现实中的 C++ 代码库

• 人们区分“理想化的现代 C++”与现实中杂乱、遗留、风格混杂的代码，而后者才是行业主流。
• 较老的 C++03 时代系统被认为尤其难以安全演进；少数顶尖团队能做到，但许多其他团队已经失败或转向迁移。
• 即使在“现代”代码中，贡献者也报告过因标准库怪癖、迭代器失效以及编译器不会提示的细微 UB 而导致的崩溃。

Rust 和内存安全替代方案

• 许多人认为 Rust（以及程度较低的 Go、Java、Swift 等）天生就更安全，能消除大量内存错误类别。
• 也有人认为，编写良好的 C++ 与 Rust 之间的安全差距并不大，并强调 Rust 自身的 unsafe 块以及对 C 库的依赖。
• 还有人担心 Rust 的 async “着色”问题、生态成熟度，以及对第三方 crate 的大量使用（供应链和复杂性风险）。

政府指导与回应

• 一些人认为，白宫推动摆脱 C/C++ 是对数十年内存安全问题的迟来承认，说明语言本身就是核心问题。
• 另一些人强调务实：C++ 已深深扎根（操作系统、浏览器、机器人、金融、嵌入式），不可能简单丢弃，必须通过工具和配置文件让它更安全。
• 也有人怀疑，持续推进中的 C++ 安全提案（profiles、“C++ v2”）是否能足够快地落地或被采用，毕竟对于新项目，直接选择 Rust 或其他更安全的语言往往更现实。