C++ 发明者 Bjarne Stroustrup 向 DevClass 讲述了如何编写现代 C++、尝试替换该语言所面临的问题、人工智能风险，以及为什么拥有多个实现略有不同的编译器实际上是一件好事。
在本周于慕尼黑举行的 Qt World 峰会上，我们在 Stroustrup 就“21 世纪 C++”发表演讲之前对他进行了采访。
尽管他的讲座名称如此，Stroustrup 的重点并非 C++ 26（下一个主要版本）即将推出的功能，例如反射和契约。“这门语言不仅仅是最新加入的功能，”他说。“要编写当代 C++，你必须结合使用从早期到现代的各种功能……我的主要观点并非说有一些简洁的新特性你绝对应该使用。而是你应该使用现在的语言。它是一个更加连贯的整体，更高效，更具表现力，也更安全。”
为了达到现代模式，每个程序员都应该使用 C++ 的哪些特性？
“很多都与功能协同工作有关，”Stroustrup 说。“我致力于让语言表达得更直接。比如，如果你想写一个循环，你不必使用循环变量。95% 到 99% 的循环都是通过这个容器执行所有操作的，所以你可以写‘for x in y’或其他什么的，直接表达你想要的内容。这样编译器更容易优化，你也更难犯错，而且写起来也更简洁。”
Stroustrup 还引用了泛型编程，他说“类型通常是推导出来的，所以你总能得到正确的类型。”
他还提到另一件至关重要的事情是资源管理。“如果你使用 RTTI 来保证删除、关闭或执行其他操作，那么你就拥有了一个操作范围。因此，每个资源都应该归属于一个句柄，并且该句柄应该位于该范围内，这样很多泄漏就会消失。”
现代 C++ 开发人员绝对不应该做的事情有哪些？
例如，永远不要使用裸指针作为资源句柄。那样你就违反了我所说的一切。永远不要像传递数组指针那样，用单个裸指针传递一组元素。你不知道里面有多少个元素。你无法进行像样的范围检查。如果你传递一个向量，它知道它有多少个元素，也知道它有哪些类型。
顺便说一句，我几乎再也不用强制类型转换了，那是通用编程的东西。如果不使用强制类型转换，很多类型错误就无法避免了。
传统上，从函数中获取大量数据的方法是，将数据放入空闲存储空间（动态存储空间），然后传递一个指针，并且必须记住迟早要删除它。现在，你可以直接将向量移出。这通常是零成本的。
在他的演讲中，Stroustrup 还谈到了模块，它使用 import 语句，而不是老旧的 #include 语句。使用 #include 是传递性的（顺序很重要），会导致重复编译，并且可能引入一些细微的错误。相比之下，import 语句不具有传递性，很多编译只需进行一次。
他重点强调的其他特性包括模板和概念（自 C++ 20 以来，它们一直是 C++ 的必备部分）。他在幻灯片中谈到这个主题时说：“使用概念比不使用更容易。”他还表示，他在生产代码中不会使用“任何比你在本次演讲中看到的更高级的东西”，并且多年来，经过基本测试后，他从未发现过资源泄漏。
如何强制以现代风格编写 C++？Stroustrup 告诉我们，这是一个问题。“你实际上无法在大量代码中遵循准则。我们需要这方面的支持。我正在研究一种由我称之为配置文件的东西强制执行的准则，它说，我想要这套保证，然后它就会被强制执行。”
他说，试图从语言本身中移除“危险、复杂的东西”是没有前途的，尽管“人们一直在要求更简单的 C++ 版本”。他告诉我们，问题在于“指针、数组、强制类型转换等等危险、复杂的东西，正是我们实现良好抽象所需要的……你能做的是，在抽象实现之外移除它们。例如，new 运算符和 delete 运算符就不应该出现在应用程序代码中。”
不过，他很失望，因为 C++ 规范中没有对配置文件的支持，而且短期内也不会支持。“可悲的是，标准委员会搞混了，没能保证 C++ 26 中会支持配置文件，”他告诉我们。
与此同时，开发人员可以使用Clang-Tidy之类的工具。“它包含我所说的 C++ 核心指南的部分检查，这是与 Red Hat、微软和其他公司合作的项目，”他说。
他是否担心人工智能对 C++ 编程的影响？“是的，我确实非常担心。我不是说它没有帮助，但它确实倾向于引导人们去做过去每个人都在做的事情。这不是一个好的方向。此外，我担心人们会因为习惯了别人替他们做事而失去发现问题的能力。”他说道。
另一个趋势是新语言的出现，其中一些基于C++，例如谷歌的Carbon项目。这些语言未来可期吗？
“如果你专注于一个领域很小的领域，设计出比 C++ 更好的语言很容易，但 C++ 的优势之一在于它适用于非常多样化的领域，”Stroustrup 说。另一个问题是，“如果任何一种语言成功了，它们必须能够与 C++、Python 等语言交互。因此，如果我们不加注意，我们得到的不是像 C++ 那样过于庞大的语言，而是 10 种能力不足、每一种都拼命地试图与其他语言互操作的语言。”
C++ 是否发展得太慢了？
“判断你进展速度是否正确的一个方法是，一半人抱怨你太慢，另一半人抱怨你太快，”Stroustrup 说。“是的，我希望进展速度比标准委员会快一点。标准委员会规模庞大，成员要处理很多事情，这会减慢进度……但可能更多的 C++ 开发者认为进展太快了，”他告诉我们。
各种 C++ 编译器在实际实现上与官方规范有所不同，这会给开发人员带来麻烦吗？
是的，但每个主流编译器，以及每个不算主流的嵌入式编译器，可能都比大多数语言拥有更多的用户……另外，我真的不喜欢单一文化。如果你回顾历史，就会发现，单一文化只要出现 bug 或出现某种毒害，就完蛋了。
Stroustrup 告诉我们，主流 C++ 编译器的实现“并不完全相同，但非常接近，而且还在不断接近”。“如果只有一个实现，会有一些优势，但最终会形成单一文化。事实上，存在多个实现意味着存在竞争，也意味着有一定的创新空间。同时也意味着它们并非完全相同……我相信，目前不存在完全兼容的 C 编译器，而且从来没有过。”
评论