C++ 被广泛认为是最强大、最通用的编程语言之一。它将高性能与对系统资源的精细控制结合在一起,这正是它被广泛使用的原因。
为什么解决 C++ 的安全问题花了这么长时间?是因为 C++ 社区的抵制,还是因为这个问题本身就难以解决?
C++ 社区与开发者文化
在讨论 C++ 的安全问题时,Reddit 和 Stack Overflow 等热门论坛上的一个常见主题是责怪开发者没有遵循最佳实践。许多活跃的 C++ 开发者认为,语言本身并非天然不安全,而是开发者未能运用现代工具和编码规范。
然而,这群发声的开发者并不一定代表 C++ 社区的大多数。虽然他们的声音主导着网络讨论,但还有一个沉默的大多数,他们可能不认同这些观点,却被确保 C++ 代码安全的复杂性和负担压得喘不过气。许多经验丰富的开发者确实承认,尽管有最佳实践,问题依然存在。
C++ 标准委员会的做法
C++ 标准委员会早就认识到 C++ 的安全挑战,但面临着艰巨的任务:既要解决这些问题,又不能破坏现有代码库或牺牲性能。语言对向后兼容的重视减缓了进展,安全机制必须逐步引入,以确保旧的关键系统继续无中断运行。
C++11、C++14 以及更新的版本(如 C++17 和 C++20)引入了重大的安全改进,例如:
- 智能指针(
std::shared_ptr,std::unique_ptr),避免手动内存管理。 std::optional,更安全地处理可选值。std::variant,避免不安全的联合体。
尽管有这些进步,C++ 安全问题的最终解决方案——即真正内存安全的 C++——并未及时到来,许多公司已转向其他天然更安全的语言。结果是,一些大公司已开始迁移到Rust和Go等语言,它们在设计上提供了更强的安全保证,尤其是在并发编程和内存管理方面。
尤其是 Rust,正越来越受欢迎,因为它在编译期强制执行内存安全而不牺牲性能。其所有权模型确保缓冲区溢出、悬空指针和释放后使用等内存问题几乎不可能发生。公司将 Rust 用于系统级开发这一事实表明,尽管 C++ 委员会在提升安全性方面取得了进展,但这些努力还不足以阻止一些组织另寻他路。
C++ 安全问题迟迟未能解决,源于两个因素的结合:问题本身的复杂性,以及社区内部的一些抵制。
- 固有的复杂性:C++ 旨在提供对内存的底层控制,这是其关键优势之一,但也是主要的安全挑战。同时实现高性能和安全性是一个艰难的平衡。由于 C++ 广泛用于关键系统,哪怕是轻微的性能回退都可能代价高昂,要找到既增强安全又不牺牲速度的方案在技术上充满挑战。而对数十年历史代码库的向后兼容需求,也让根本性变更困难得多。
- 社区抵制:C++ 社区中的一些人,尤其是更有经验的开发者,抵制某些可能强制更严格内存规则或更高层抽象的安全措施,因为他们认为这些改变会削弱 C++ 的性能优势。此外,C++ 开发者往往更看重最佳实践,而非语言本身的安全保证,认为严谨地使用语言就能避免大多数陷阱。
结语
C++ 社区整体并未在安全问题上完全“把头埋进沙子里”。然而,社区对开发者责任和最佳实践的强调,造成了一种印象:这门语言的风险完全可以由熟练的开发者管控。相比之下,许多行业专家和公司认识到,C++ 的安全仍是一个尚未完全解决的重大挑战,这促使他们转向内置安全机制的更新语言。
尽管 C++ 标准委员会多年来取得了重大进展,但这些变化缓慢、渐进的特性,加上语言的复杂性,让一些人质疑:对那些把安全置于首位的行业来说,这一切是否太少、太迟。