C++ 会变成像 Rust 一样的安全语言吗
https://img-blog.csdnimg.cn/direct/ca2365b372b04a1892426b16b41df23e.pngC++ 是否会变成像 Rust 一样的安全语言，这个问题涉及多个方面，包括语言设计、开发者社区的态度、以及将来可能的语言改进等。以下是对此问题的详细分析：
[*] 语言设计：
[*]Rust 是一种注重内存安全的编程语言，通过全部权（Ownership）、借用（Borrowing）和生命周期（Lifetimes）等机制，从根本上解决了内存安全问题。这些机制确保了数据的安全性和可靠性，使 Rust 在处置惩罚加密和安全通讯方面具有独特的上风。
[*]C++ 在设计上虽然也提供了一些类型安全掩护措施，如强类型系统、访问控制、函数重载、引用与指针区分、自定义类型转换的查抄以及异常处置惩罚等，但作为一门系统级、底层的语言，C++ 的类型安全性仍不如 Java、C# 等语言。别的，C++ 的内存管理相对复杂，必要程序员手动管理内存，这增加了内存泄漏和悬挂指针等问题的风险。
[*]为了使 C++ 变得更加安全，C++ 专家和 ISO C++ 委员会主席 Herb Sutter 提出了一些方法，包括依靠工具、推广安全语言特性、不安全特性必要显式启用等。这些方法旨在减少无意的风险，但并不意味着 C++ 会完全变成像 Rust 一样的安全语言。
[*] 开发者社区的态度：
[*]Rust 和 C++ 在开发者社区中有差别的定位和用途。Rust 因其内存安全性而备受关注，特别适用于必要高度安全性的领域，如操作系统、嵌入式系统和网络服务等。而 C++ 则因其高效的性能、机动的语法和广泛的库支持而广泛应用于系统级编程、游戏开发、图形界面开发等领域。
[*]因此，即使 C++ 在某些方面进行了改进以进步安全性，也不太可能完全放弃其原有的特性和上风，变成与 Rust 完全雷同的语言。相反，C++ 可能会继承在保持其性能上风的同时，通过添加新的特性和改进来进步安全性。
[*] 将来可能的语言改进：
[*]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 个源于越界读、越界写、空指针解引用和访问已开释内存。
https://img-blog.csdnimg.cn/img_convert/9638197d75e220d23af4e68b62af85d1.png
根据 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 的工作，其目的是使逐步采用更安全的行为并在编译时强制执行安全规则成为可能。https://img-blog.csdnimg.cn/direct/b71dd5e8137343a2b4f60068cebf4a52.jpeg
“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())
```
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]