导读：当前版本的 Safe C++ 将耗时 18 个月设计和实现。但它能满足开发人员的所有需求与表现力吗？

为了避免与内存相关的错误，通常的建议让 C++ 开发人员改用Rust。但是，还有其他的选择项吗？

第 21 工作组（成立于 1990 年，由“对 C++ 工作感兴趣的……公认专家”组成） 在 9 月份 的 邮件中发布了一项提案  ，此后，这项“安全 C++ 扩展”提案在网上引发了大量讨论。

这一切都表明 C++ 社区正在开展一项更大规模的运动，为这门已有 39 年历史的编程语言探索新的解决方案，以解决内存安全方面的持续担忧。这项安全 C++ 提案只是正在进行的努力的一部分，其他想法和方法也在提出和讨论中。

而这次对话的背景是，更广泛的编程社区对更安全代码的需求越来越大。因此，新的 Safe C++ 提案首先承认，对 C++ 的持续批评“削弱了该语言对新手的价值”。但随后，它还认为，Rust 的模范安全模型可以成为“加强 C++ 的机会”，并补充说，Rust 在内存安全保障方面长达十年的工作引领了潮流，并为 Safe C++ 的设计提供了很大的参考价值。

“采用安全专家一直指出的相同所有权和借用安全模型，是让 C++ 在下一代中保持可行性的明智且及时的方法。”

提出解决方案

根据两位非常敬业的开发人员撰写的提案，Safe C++ 的当前版本耗时 18 个月进行设计和实现：

• 纽约的 Sean Baxter 是一名资深开发人员，他的职业生涯包括在美国国家航空航天局 (NASA) 喷气推进实验室担任软件工程师三年半，之后担任 NVIDIA 研究科学家两年多（根据其LinkedIn 个人资料），他创建了一个名为Circle的 C++ 替代编译器。

• 住在萨克拉门托的Christian Mazakas是C++ 联盟的资深工程师，该联盟是一家 慈善机构，成立于 2017 年，其旨在通过鼓励新的代码库和语言提案，以及赞助教育计划来支持 C++ 社区。

9 月， C++ 联盟宣布与 Baxter 合作，称这是“一项革命性的提案，为 C++ 编程语言添加了内存安全功能”。公告称，C++ 联盟总裁兼执行董事 Vinnie Falco 称这是“C++ 生态系统的一个重要里程碑，因为对安全代码的需求从未如此迫切”。

那么，他们是如何实现的？该提案的一个“关键部分”是使用所谓的安全标准库来扩充 C++ 标准库：“关键数据结构和算法的健壮、内存安全的实现，通过将这些组件集成到 C++ 标准库中，我们可以确保新代码从一开始就考虑到安全性。”

正如其文档中所说，“安全第一。安全 C++ 开发人员不得编写可能导致生命周期安全、类型安全或线程安全未定义行为的操作。有时这些操作会被编译器前端禁止，指针算法就是这种情况。有时这些操作会被编译器中端的静态分析禁止，从而阻止未初始化变量的使用和释放后使用错误，这是所有权和借用安全模型的使能技术。其余问题，如越界数组下标，则通过运行时恐慌和中止来解决。”

但“当前是一套新功能，可以改进那些拒绝向用户提供的不安全功能”，包括新的模式匹配和复杂的借用检查（跟踪引用，以避免出现释放后使用漏洞的可能性）。

不断发展的工具链

对于 Baxter 来说，这是他一个长期的兴趣。 

早在 2019 年，他就创建了 Circle，这是一款新型 C++ 编译器，他说只需改进工具链，它就能提供成熟后继语言的全部优势。从定义上讲，此方法与现有的 C++ 代码完全兼容。正是在 Circle 中，Baxter 首次为 C++ 实现了类似 Rust 的借用检查器——但即使如此，Baxter 仍对 C++ 代码的长期命运表现出了更大的兴趣。

Baxter 在 2022 年宣布推出 Circle 的新版本时，向那些 C++ 批评者发起了挑战，后者称该语言本质上存在缺陷/不安全/编译速度慢等问题。他说：

“软件可以做它该做的事，只要付出努力，就可以做一些新的事情。这里记录的技术扩展了 C++ 工具链，可以修复语言缺陷，使语言更安全、更高效，同时保持与现有代码资产 100% 的兼容性……

“未来的 C++ 不仅仅是一种语言。它是编程朝着更安全、更简单、更高效的方向发展的起点，同时保持与现有 C++ 资产的互操作性。”

那么为什么不让每个人都改用 Rust 呢？新的 Safe C++ 提案清晰说明了这一点。

“Rust 对于职业 C++ 开发人员来说很陌生，再加上互操作工具的摩擦，使得通过用 Rust 重写关键部分来强化 C++ 应用程序变得很困难。为什么没有针对内存安全的语言解决方案？为什么不使用 Safe C++？”

最近一篇文章回顾了从研究人员到Microsoft Azure 首席技术官 Mark Russinovich，甚至美国国家安全局和白宫等各界人士发出的警告记录。

Baxter 亦承认：“政府最近对内存安全的警告已引起全球科技行业的关注。”

“我研究了理论，并看到了使用新工具的机会，可以帮助 C++ 工程师编写更正确的程序并消除与安全漏洞最相关的软件缺陷。”

资料发生了什么变化？

这并不是改进 C++ 的唯一想法。

在13 个月前，C++ 创始人 Bjarne Stroustrup 在 CppCon 上告诉社区开发者，该语言的现状是“一个机会”，并补充说，从该语言诞生之初，类型和资源安全就一直是目标。Stroustrup 还建议使用配置文件改进该语言——可能由编译器检查的安全保障规则。

标准 C++ 基金会 (由微软、谷歌和英特尔等支持的非营利组织) 的 GitHub 存储库中的配置文件已经引发了开发者们一些思考。

它有一个由 Bjarne Stroustrup 和 ISO C++ 标准委员会主席Herb Sutter合作编辑的 C++ 核心指南页面。该页面现在包括对“相关规则组”(称为配置文件) 的引用，用以实现类型安全和边界安全等期望结果。

“这些配置文件旨在供工具使用，但也可以作为人类读者的辅助工具。我们不会将执行部分的评论限制在我们知道如何执行的事情上；有些评论仅仅是一些可能启发一些工具构建者的愿望。”

但上周四（10 月 24 日），Baxter 发表了一篇新论文，题为“安全概况为何失败”。

“安全配置文件于 2015 年推出，承诺检测现有 C++ 代码中的所有终身安全缺陷。这是一个大胆的主张。但经过十年的努力，配置文件未能为 C++ 安全提供规范、可靠的实现或任何切实的好处。这一失败的原因涉及其设计核心中的许多错误前提。”

该论文还指出，就目前而言，C++ 源代码“没有足够的信息来实现内存安全……”并建议“将 Rust 的安全模型纳入 C++”（这也将提高 Rust 和 C++ 之间的互操作性）。“通过使用可以出现在函数声明中的所有 Rust 构造的表示来扩展 C++（例如 Rust 枚举、借用和生命周期、ZST、特征等），可以大大增加常用词汇类型的数量……

“C++ 可以实现内存安全，但不能通过摒弃所有可行的方法来实现，而这正是《安全配置文件》的作者们所做的。”该论文认为，C++ 必须“不断发展，以更明确地表达别名、生命周期与安全属性。”

协作的过程

此项讨论正在进行中，而且人们希望讨论到更多内容。

除了宣布该提案外，Baxter 和联盟还宣布他们正在“寻求开发人员、研究人员和其他利益相关者的反馈”，并相信协作过程“将有助于完善项目范围并确保其满足 C++ 生态系统最紧迫的需求”。

“有了业界的参与，我们可以解决剩余设计问题，”他们的提案指出，“再过 18 个月，我们就能拥有一门足够强大的语言与标准库，供主流社区评估。虽然 Safe C++ 是该语言的一大扩展，但构建新工具的成本并不高……我们正在共同设计 Safe C++ 标准库和语言扩展。欢迎访问我们的存储库以关注我们的工作。”

从 6 月份开始，“ SafeCPP.org ”域名已经开通——现在会自动将所有访问者重定向到 Safe C++ 提案的 draft.html 页面。

作者：聆听音乐的鱼