C++ 会变成像 Rust 一样的安全语言吗

C++ 是否会变成像 Rust 一样的安全语言，这个问题涉及多个方面，包括语言设计、开发者社区的态度、以及未来可能的语言改进等。以下是对此问题的详细分析：

1. 语言设计：- Rust 是一种注重内存安全的编程语言，通过所有权（Ownership）、借用（Borrowing）和生命周期（Lifetimes）等机制，从根本上解决了内存安全问题。这些机制确保了数据的安全性和可靠性，使 Rust 在处理加密和安全通信方面具有独特的优势。- C++ 在设计上虽然也提供了一些类型安全保护措施，如强类型系统、访问控制、函数重载、引用与指针区分、自定义类型转换的检查以及异常处理等，但作为一门系统级、底层的语言，C++ 的类型安全性仍不如 Java、C# 等语言。此外，C++ 的内存管理相对复杂，需要程序员手动管理内存，这增加了内存泄漏和悬挂指针等问题的风险。- 为了使 C++ 变得更加安全，C++ 专家和 ISO C++ 委员会主席 Herb Sutter 提出了一些方法，包括依赖工具、推广安全语言特性、不安全特性需要显式启用等。这些方法旨在减少无意的风险，但并不意味着 C++ 会完全变成像 Rust 一样的安全语言。

2. 开发者社区的态度：- Rust 和 C++ 在开发者社区中有不同的定位和用途。Rust 因其内存安全性而备受关注，特别适用于需要高度安全性的领域，如操作系统、嵌入式系统和网络服务等。而 C++ 则因其高效的性能、灵活的语法和广泛的库支持而广泛应用于系统级编程、游戏开发、图形界面开发等领域。- 因此，即使 C++ 在某些方面进行了改进以提高安全性，也不太可能完全放弃其原有的特性和优势，变成与 Rust 完全相同的语言。相反，C++ 可能会继续在保持其性能优势的同时，通过添加新的特性和改进来提高安全性。

3. 未来可能的语言改进：- C++ 是一种活的语言，会随着时间的推移而进化。未来 C++ 可能会引入更多的安全特性和工具来减少与内存安全相关的漏洞。然而，这并不意味着 C++ 会完全变成像 Rust 一样的安全语言。相反，C++ 可能会继续在其核心特性上进行改进和扩展，以满足不同领域的需求。

综上所述，虽然 C++ 可能会在未来进行一些改进以提高安全性，但它不太可能完全变成像 Rust 一样的安全语言。这是因为 C++ 和 Rust 在设计目标、应用场景和开发者社区的态度等方面存在差异。C++ 可能会继续在保持其性能优势的同时，通过添加新的特性和改进来提高安全性。

对于如何使 C++ 成为一种类似 Rust 及其他内存安全语言（MSL）的安全语言，C++ 专家、ISO C++ 委员会主席 Herb Sutter 在最近的一篇文章中表达了他的看法。他的方法包括依赖工具（与其他 MSL 一样）、推广安全语言特性、不安全特性需要显式启用等等。

Sutter 指出，为了使 C++ 变得更加安全，首先要解决 4 种主要的内存安全相关的漏洞。实际上，在总共 12 类与内存安全相关的漏洞中（约占所有 CVE 的 70%），有 4 个源于越界读、越界写、空指针解引用和访问已释放内存。

根据 Sutter 的说法，C++ 已经对编写安全代码提供了广泛的支持，而且 C++ 文献早就确定了用于实现这一目标的关键规则。不过，他认为，作为一种关键的语言特性，C++ 应该严格执行这些规则，只有当程序员明确选择不遵循标准规则时，才可以使用不安全行为。

默认启用安全规则不会限制这门语言的能力，但若要采用非标准实践就需要显式做出选择，从而减少无意的风险。它可以随着时间的推移而进化，这一点很重要，因为 C++ 是一种活的语言，而敌手会不断地改变他们的攻击手法。

Sutter 还描述了一些错误的问题和认识。他指出，大多数高严重性 CVE 都与内存安全无关（尽管越界写是罪魁祸首）；MSL 也有 CVE；MSL 也依赖于静态分析程序和杀毒程序等工具。因此，最终目标不可能是让 C++ 程序完全摆脱与内存安全相关的 CVE，也不是在不依赖工具的情况下强制执行内存安全规则或者使 C++ 代码在形式上可证明。

在他的文章中，Sutter 重启了一个关于 C++ 内存安全的讨论，那是由 2023 年美国国家安全局网络安全信息表引发的，它建议人们远离 C/C++ 以及其他内存不安全的语言。

作为对 NSA 报告的回应，Bjarne Stroustrup 表达了他的观点，即 C++ 可以像 Rust 一样安全，而且不用像后者那么复杂：

C++ 核心指南旨在为那些需要静态类型安全和资源安全的 C++ 开发人员提供这方面的保证，而且不会破坏代码库，他们可以在没有这类强力保证或不额外引入工具链的情况下对代码库进行管理。

在这里，Stroustrup 含蓄地指出，ISO 委员会正在开展有关 C++ profilse 的工作，其目的是使逐步采用更安全的行为并在编译时强制执行安全规则成为可能。

“Profile”是一组确定性的（deterministic）、便于强制执行（portably enforceable）的规则子集（即限制），旨在实现特定的保证。“确定性”意味着它们只需要局部分析，并且可以在编译器中实现（尽管它们不必如此）。“便于强制执行”意味着它们就像语言规则一样，程序员可以使用不同的强制执行工具，而且不同的工具对于相同的代码会给出同样的答案。

特别地，C++ profiles 包括类型安全、边界安全和生命周期安全。根据 Stroustrup 的说法，符合 profiles 规则的代码是安全的，因为其中包含安全保障。

Stroustrup 对 NSA 报告的批评引起了有些人的注意，Jimmy Hartzell 就提出了一些有根据的批评，其中包括 C++ 还不是一种内存安全的语言，线程安全等领域的考虑还比较欠缺，而 Rust 已经有很多与之相关的机制。

现在，甚至在系统编程领域，C++ 也受到 Rust（一种强大的内存安全编程语言，而且可以避免 C++ 的许多问题）的威胁。即使是在 C++ 非“遗留”的领域，也有了可行的、内存安全的替代方案，而且没有像 C++ 那么多的技术债务。

回到 Sutter 的观点，和 Stroustrup 一样，他也相信，profiles 是使 C++ 更安全的一个关键特性，可以将 C++ 代码中类型 / 边界 / 初始化 / 生命周期相关的 CVE 减少 98%，而又不限制 C++ 的能力：

我不希望 C++ 限制我的表达能力。我只是希望 C++ 能默认执行我们已经熟知的安全规则和最佳实践，如果我想的话，我也可以明确地选择不遵守。然后，我仍然可以使用完全现代化的 C++……只是更友善一些。

在文章的最后，为了帮助 C++ ISO 委员会达成 98% 的目标，他提出了一些广泛而具体的建议。相关细节，错过可惜。

```python
class BertPooler(nn.Module):
    def __init__(self, config):
        super().__init__()
        self.dense = nn.Linear(config.hidden_size, config.hidden_size)
        self.activation = nn.Tanh()

    def forward(self, hidden_states):
        # We "pool" the model by simply taking the hidden state corresponding
        # to the first token.
        first_token_tensor = hidden_states[:, 0]
        pooled_output = self.dense(first_token_tensor)
        pooled_output = self.activation(pooled_output)
        return pooled_output
from transformers.models.bert.configuration_bert import *
import torch
config = BertConfig.from_pretrained("bert-base-uncased")
bert_pooler = BertPooler(config=config)
print("input to bert pooler size: {}".format(config.hidden_size))
batch_size = 1
seq_len = 2
hidden_size = 768
x = torch.rand(batch_size, seq_len, hidden_size)
y = bert_pooler(x)
print(y.size())

```