编程与软件工程alexgaynor.net
现代 C++ 救不了我们
Modern C++ Won't Save Us
2019 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Alex Gaynor 在文中指出：C++17 等「现代 C++」新特性并不能真正让 C++ 变得安全——string_view、span、optional 等工具表面上提升了表达力，却依然把生命周期和边界检查的责任留给程序员，稍有不慎就是悬垂引用或未定义行为。作者认为这些缺陷源于语言本身的历史包袱和设计取舍，靠增量特性补不回来。
为什么经久不衰：它用具体代码例子点破了「用新特性就能让 C++ 变安全」的幻觉，是理解 C++ 内存安全问题与 Rust 等替代方案之争的一份经典短论，多年后仍被反复引用。
HN 评论精选
标准库受限于历史包袱，反而拖累了现代 C++ 的可用性。
我对 C++ 的一大意见是：即使你的代码库是纯 C++17，标准库本身也是新旧 C++ 混杂的缝合怪，里面充满了各种妥协。一个能干净地展示 C++17 全部能力的标准库，必须放弃相当多的向后兼容。我注意到越来越多像我这样的人在用大型的「另一条时间线」标准库，补充功能、重新设计，甚至在现代 C++ 的干净基础上重写核心组件，结果就是代码库里标准库的使用在萎缩。
jandrewrogers查看英文原文
A significant issue I have with C++ is that even if your code base is pure C++17, the standard library is a Frankenstein's monster of legacy and modern C++ mixed together that required many compromises to be made. A standard library that usefully showed off the full capabilities of C++17 in a clean way would have to jettison a fair amount of backward compatibility in modern C++ environments. I've noticed that more and more people like me have and use large alternative history "standard libraries" that add functionality, reimagine the design, and in some cases reimplement core components based on a modern C++ cleanroom. I've noticed that use of the standard library in code bases is shrinking as result. You can do a lot more with the language if you have a standard library that isn't shackled by its very long history.
没有借用检查器，所有权和借用只能靠约定而非编译器保证。
C++ 社区试图在不引入借用检查器的情况下把所有权概念塞进语言，这很痛苦。他们让人可以写出表达所有权的代码，却抓不住所有抽象泄漏的地方。string_view 本质上就是一个不可变的借用，但编译器并不知道这一点。
Animats查看英文原文
The C++ people are trying to refit ownership to the language without adding a borrow checker. This is painful. They've made it possible to write code that expresses ownership, but they can't catch all the places where the abstraction leaks. string_view is really a non-mutable borrow. But the compiler does not know this.
Rust 前景可观，但现有生态还无法替代不少 C++ 的实际使用场景。
确实，C++ 有不少伤疤，其中一些来自与 C 的复制粘贴式兼容。这既是福也是祸：福在于我们这些 Pascal/Ada/Modula 难民不必再去碰那种在九十年代初就已过时的不安全语言；祸在于当团队成员或第三方库在代码里用 C 式写法时，我们很难阻止，也就很难写出安全的代码。至于替代方案，Swift 在苹果平台之外根本不在考虑范围内；Rust 有朝一日也许可以，尤其现在谷歌、微软、亚马逊、Dropbox 都在采用它。但对我们很多人来说，它目前仍覆盖不了我们用 C++ 的场景，我总不能为了自我感觉良好，就让团队和客户多花一倍时间。等有了带混合模式调试、Blend 集成和 COM/UWP 语言投影的 Visual Rust，那再说吧。
pjmlp查看英文原文
It is true, C++ has several warts some of them caused by the copy-paste compatibility with C. Which is both a blessing and a curse. A blessing as it allowed us Pascal/Ada/Modula refugees never to deal with what was already outdated, unsafe language by the early 90's. But also makes it relatively hard to write safe code when we cannot prevent team members, or third party libraries, to use Cisms on their code. Regarding the alternatives, Swift is definitly not an option outside Apple platforms. And even there, Apple still focus on C++ for IO Kit, Metal and LLVM based tooling. Rust, yes. Some day it might be, specially now with Google, Microsoft, Amazon, Dropbox,... adopting it across their stacks. However for many of us it still doesn't cover the use cases we use C++ for, so it is not like I will impose myself, the team and customers, a productivity pain, take the double amount of time that it takes to write a COM component or native bindings in C++ for .NET consumption just to feel good. When we get Visual Rust, with mixed mode debugging, Blend integration and a COM/UWP language projection for Rust, then yeah.
实践者对比：Rust 默认不可变和工具链体验远胜 C++，尽管自身也有代价。
这是我这个只用 C++ 和 Rust 各写过一份生产软件的人的看法：写 C++ 时我一直在和意外的内存拷贝搏斗，在 Rust 里这些都很轻松，一切都符合预期——这基本就是我选 Rust 而非 C++ 的原因。作为初学者，我完全不知道该怎么优雅地写不可变数据和并行代码；在 Rust 里只要 .iter() 换成 .par_iter()，因为默认一切都是不可变的。C++ 的包管理糟透了（等于没有），头文件既烦人又没意义。我知道话说得重，这只是我的看法，但那些声称 C++ 挺好的人，我觉得是斯德哥尔摩综合征。Rust 也远非完美：代码常像乱码，小项目目录也占好几个 G，编译慢，工具链时好时坏——但这仍比一步步谷歌「CMake 怎么用」好上好几个数量级。
127查看英文原文
Here's the point of view from someone who has only written 1 piece of production software with both C++ and Rust. Trying to write C++ I was constantly fighting accidental memory copies. With Rust all of this was trivial and everything works as I expect. This is pretty much the reason I chose Rust over C++. As a beginner I have no idea how I would begin to elegantly write immutable data, parallel code. With Rust it's just .iter() to .par_iter() (everything is immutable by default). C++ package management is awful (it has none). C++ headers are annoying and pointless. I know these are strong statements and of course only my opinion but I just see people claiming C++ is fine just having a strong case of Stockholm Syndrome. Rust is nowhere perfect. Often it can look like line noise, the project folder takes multiple gigabytes even for small-ish projects, the compilations can be slow, the tooling is not always there. This is still multiple orders of magnitudes better than trying to Google how Cmake works step by step. On the other hand I love rustanalyzer + vscode. It was super easy to get going with and just works. Visual Studio C++ seems to be much more steep as a learning curve.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选