mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
163 lines
13 KiB
Markdown
163 lines
13 KiB
Markdown
# 关于 C ++ 的所有争论？Bjarne Stroustrup 警告他的 C++ 未来的计划很危险
|
||
|
||
|
||
|
||
今年早些时候，我们**访谈**了 Bjarne Stroustrup，他是 C++ 语言的创始人，摩根士丹利技术部门的董事总经理，美国哥伦比亚大学计算机科学的客座教授，他写了[一封信][1]邀请那些关注编程语言演进的人去“想想瓦萨号！”
|
||
|
||
毫无疑问，对于丹麦人来说，这句话很容易理解，而那些对于 17 世纪的斯堪的纳维亚历史了解不多的人，还需要展开说一下。瓦萨号是一艘瑞典军舰，由国王 Gustavus Adolphus 委托建造。它是在 1628 年 8 月 10 日首航时，当时波罗的海国家中最强大的军舰，但是它在首航几分钟之后就沉没了。
|
||
|
||
巨大的瓦萨号有一个难以解决的设计缺陷：头重脚轻，以至于它被[一阵狂风刮翻了][2]。通过这段翻船历史的回忆，Stroustrup 警示了 C++ 所面临的风险，因为现在越来越多的特性被添加到了 C++ 中。
|
||
|
||
现在已经提议了不少这样的特性。Stroustrup 在他的信中引用了 43 条提议。他认为那些参与 C++ 语言 ISO 标准演进的人（指众所周知的 [WG21][3]），正在努力地让语言更高级，但他们的努力方向却并不一致。
|
||
|
||
在他的信中，他写道：
|
||
|
||
> 分开来看，许多提议都很有道理。但将它们综合到一起，这些提议是很愚蠢的，将危害 C++ 的未来。
|
||
|
||
他明确表示，不希望 C++ 重蹈瓦萨号的覆辙，这种渐近式的改进将敲响 C++ 的丧钟。相反，应该吸取瓦萨号的教训，构建一个坚实的基础，吸取经验教训，并做彻底的测试。
|
||
|
||
在瑞士拉普斯威尔（Rapperswill）召开的 C++ 标准化委员会会议之后，本月早些时候，Stroustrup 接受了_《The Register》_ 的采访，回答了有关 C++ 语言下一步发展方向方面的几个问题。（最新版是 C++17，它去年刚发布；下一个版本是 C++20，它正在开发中，预计于 2020 年发布。）
|
||
|
||
**Register：在你的信件《想想瓦萨号！》中，你写道：**
|
||
|
||
> 在 C++11 开始基础不再完整，而 C++17 中在使基础更加稳固、规范和完整方面几乎没有改善。相反地，却增加了重要接口的复杂度，让人们需要学习的特性数量越来越多。C++ 可能在这种提议的重压之下崩溃 —— 这些提议大多数都不成熟。我们不应该花费大量的时间为专家级用户们（比如我们自己）去创建越来越复杂的东西。~~（还要考虑普通用户的学习曲线，越复杂的东西越不易普及。）~~
|
||
|
||
**对新人来说，C++ 很难吗？如果是这样，你认为怎样的特性让新人更易理解？**
|
||
|
||
**Stroustrup：**C++ 的有些东西对于新人来说确实很难。
|
||
|
||
换句话说，C++ 中有些东西对于新人来说，比起 C 或上世纪九十年代的 C++ 更容易理解了。而难点是让大型社区专注于这些部分，并且帮助新手和普通 C++ 用户去规避那些对高级库实现提供支持的部分。
|
||
|
||
我建议使用 [C++ 核心准则][4] 作为实现上述目标的一个辅助。
|
||
|
||
此外，我的 “C++ 教程” 也可以帮助人们在使用现代 C++ 时走上正确的方向，而不会迷失在自上世纪九十年代以来的复杂性中，或困惑于只有专家级的用户才能理解的东西中。第二版的 “C++ 教程” 涵盖了 C++17 和部分 C++20 的内容，这本书即将要出版了。
|
||
|
||
我和其他人给没有编程经验的大一新生教过 C++，只要你不去深挖编程语言的每个晦涩难懂的角落，把注意力集中到 C++ 中最主流的部分，在三个月内新可以学会 C++。
|
||
|
||
“让简单的东西保持简单” 是我长期追求的目标。比如 C++11 的 `range-for` 循环：
|
||
|
||
```
|
||
for (int& x : v) ++x; // increment each element of the container v
|
||
|
||
```
|
||
|
||
`v` 的位置可以是任何容器。在 C 和 C 风格的 C++ 中，它可能看到的是这样：
|
||
|
||
```
|
||
for (int i=0; i<MAX; i++) ++v[i]; // increment each element of the array v
|
||
|
||
```
|
||
|
||
一些人报怨说添加了 `range-for` 循环让 C++ 变得更复杂了，很显然，他们是正确的，因为它添加了一个新特性，但它却让 C++ 用起来更简单。同时它还解决掉了传统 for 循环中出现的一些常见错误。
|
||
|
||
另外的一个例子是 C++11 的标准线程库。它比起使用 POSIX 或直接使用 Windows 的 C API 来说更简单，并且更不易出错。
|
||
|
||
**Register：你如何看待 C++ 现在的状况？**
|
||
|
||
**Stroustrup：** C++11 是 C++ 的最重大的改进版，并且在 C++14 上全面完成了改进工作。C++17 添加了相当多的新特性，但是没有提供对新技术的很多支持。C++20 目前看上去可能会成为一个重大改进版。编译器的状况和标准库实现的非常好，非常接近最新的标准。C++17 已经可用。持续改进了对工具的支持。已经有了许多第三方的库和许多新工具。而不幸的是，这些东西不太好找到。
|
||
|
||
我在《想想瓦萨号！》一文中所表达的担忧与标准化过程有关，对新东西的过度热情与完美主义的组合拖延了重大的改进。“追述完美是优秀的敌人”，在六月份拉普斯威尔的会议上有 160 人参与。在这样一个数量庞大和多样化的人群中很难取得一致意见。这就导致了专家们更多地为他们自己去设计，而不是为了整个社区。
|
||
|
||
**Register： C++ 是否有一个期望的状况，或为了期望的适应性而努力简化以满足程序员们在任意时间的需要？**
|
||
|
||
**Stroustrup：** 二者都有。我很乐意看到 C++ 支持彻底保证类型安全和资源安全的编程方式。这不应该通过限制适用性或增加成本来实现，而是应该通过改进的表达能力和性能来实现。我认为可以做到这些，通过让程序员使用更好的（更易用的）语言可以实现这一点。
|
||
|
||
终极目标不会马上实现，也不会单靠语言的设计来实现。为了让编程更高效，我们需要通过改进语言特性、最好的库、静态分析、以及规则的组合来实现。C++ 核心准则是我提升 C++ 代码质量的广泛而长远的方法。
|
||
|
||
**Register：对于 C++ 是否有明显的风险？如果有，它是如何产生的？（如，改进过于缓慢，新出现的低级语言，等等，从你的信中看，似乎是提议过多。）**
|
||
|
||
**Stroustrup：**毫无疑问，今年我们已经收到了 400 个提议。当然，它们并不都是新提议。许多提议都与规范语言和标准库这一必需而乏味的工作相关，但是量大到难以管理。你可以在 WG21 的网站上找到所有这些文章。
|
||
|
||
我写了《想想瓦萨号！》这封信作为一个呼吁。我感受到了这种压力，为解决紧急需要和赶时髦而增加语言特性，而不是去加强语言基础（比如，改善静态类型系统）。增加的任何新东西，无论它是多小都会产生成本，比如实现、学习、工具升级。重大的特性是那些改变我们编程思想的特性。那才是我们必须关注的东西。
|
||
|
||
委员会已经设立了一个”指导小组“，这个小组由在语言、标准库、实现、以及实际使用领域中拥有极强履历的人组成。我是其中的成员之一。我们负责为重点领域写一些关于方向、设计理念和建议方面的东西。
|
||
|
||
对于 C++20，我们建议去关注：
|
||
|
||
```
|
||
概念
|
||
模块(提供适当的模块化和令人称奇的编译时改进)
|
||
Ranges（包括一些无限序列的扩展）
|
||
标准库中的网络概念
|
||
```
|
||
|
||
在拉普斯威尔会议之后，虽然带来的模块和网络化很显然只是一种延伸，但机会还是有的。我是一个乐观主义者，并且委员会的成员们都非常努力。
|
||
|
||
我并不担心其它语言或新语言会取代它。我喜欢编程语言。如果一个新的语言提供了其它编程语言没有提供的非常有用的东西，那它就是我们从中学习的榜样，当然，每个语言都有它自己的问题。许多 C++ 的问题都与它广泛的应用领域、大量的使用人群和过度的热情有关。大多数语言的社区都喜欢有这样的问题。
|
||
|
||
**Register：关于 C++ 你是否重新考虑过任何架构方面的决策？**
|
||
|
||
**Stroustrup：** 当我使用一些新的编程语言时，我经常思考 C++ 原来的决策和设计。例如，可以看我的《编程的历史》论文第 1、2 部分。
|
||
|
||
并没有让我觉得很懊悔的重大决策，如果让我重新再做一次决策，几乎不会对现有的特性做任何不同的改变。
|
||
|
||
与以前一样，能够直接处理硬件加上零开销的抽象是设计的指导思想。使用构造函数和析构函数去处理资源是关键（RAII），STL 就是在 C++ 库中能够做什么的一个很好的例子。
|
||
|
||
**Register：在 2011 年采纳的每三年发布一个标准的节奏是否仍然有效？我之所以这样问是因为 Java 为了更快地迭代，一直在解决需求。**
|
||
|
||
**Stroustrup：**我认为 C++20 将会按时发布（就像 C++14 和 C++17 那样），并且主要的编译器也会立即遵从它。我也希望 C++20 比起 C++17 能有重大的改进。
|
||
|
||
对于其它语言如何管理它们的发行版我并不焦虑。C++ 是由一个遵循 ISO 规则的委员会来管理的，并不是由一个大公司或一个”创造它的权威“来管理。这一点不会改变。关于 ISO 标准，C++ 每三年发布一次的周期是一个激动人心的创举。标准的周期是 5 或 10 年。
|
||
|
||
**Register：在你的信中你写道：**
|
||
|
||
```
|
||
我们需要一个能够被”普通程序员“使用的条理还算清楚的编程语言，他们主要关心的是能否按时高质量地交付他们的应用程序。
|
||
```
|
||
|
||
对语言的改变是否能够去解决这个问题，或者还可能涉及到更多容易获得的工具和教育支持？
|
||
|
||
**Stroustrup：**我努力去宣传我的理念 —— C++ 是什么以及如何使用它，并且我鼓励其他人也和我一样去做。
|
||
|
||
特别是，我鼓励讲师和作者们向 C++ 程序员们宣扬有用易用的理念，而不是去示范复杂的示例和技术来展示他们自己有多高明。我在 2017 年的 CppCon 大会上的演讲主题就是”学习和教学 C++“，并且也指出 C++ 需要更好的工具。
|
||
|
||
我在演讲中提到构建支持和包管理器。这些历来都是 C++ 的弱点项。标准化委员会现在有一个工具研究小组，或许不久的将来也会有一个教育研究小组。
|
||
|
||
C++ 的社区以前基本上是很乱的，但是在过去的五年里，为了满足社区对新闻和支持的需要，出现了很多会议和博客。CppCon、isocpp.org、以及 Meeting++ 就是这样的例子。
|
||
|
||
在委员会中做设计是非常困难的。但是，对于所有的大型项目来说，委员会又是必不可少的。我很关注它们，但是为了成功，关注和面对问题是必需的。
|
||
|
||
**Register：你如何看待 C++ 社区的流程？在沟通和决策方面你希望看到哪些变化？**
|
||
|
||
**Stroustrup：**C++ 并没有企业管理的”社区流程“；它有一个 ISO 标准流程。我们不能对 ISO 的角色做重大的改变。理想的情况是，我们设立一个小的全职的”秘书处“来做最终决策和方向管理，但这种理想情况是不会出现的。相反，我们有成百上千的人在线来讨论，大约有 160 人在技术问题上进行投票，大约有 70 组织和 11 个国家在结果提议上正式投票。这样是很混乱的，但是在将来某个时候我们会让它好起来。
|
||
|
||
**Register：最终你认为那些即将推出的 C++ 特性中，对 C++ 用户最有帮助的是哪些？**
|
||
|
||
**Stroustrup：**
|
||
|
||
```
|
||
大大地简化了一般编程的概念
|
||
并行算法 – 没有比使用现代化硬件的并发特性更好的方法了
|
||
协程，如果委员会能够确定在 C++20 上推出。
|
||
模块改进了组织源代码的方式，并且大幅改善了编译时间。我希望能有这样的模块，但是它还不能确定能否在 C++20 上推出。
|
||
一个标准的网络库，但是它还不能确定能否在 C++20 上推出。
|
||
```
|
||
|
||
此外：
|
||
|
||
```
|
||
Contracts（运行时检查的先决条件、后置条件、和断言）可能对许多人都非常重要。
|
||
date 和 time-zone 支持库可能对许多人（行业）非常重要。
|
||
```
|
||
|
||
**Register：最后你还有需要向读者说的话吗？**
|
||
|
||
**Stroustrup：**如果 C++ 标准化委员会能够专注于重大问题，去解决重大问题，那么 C++20 将会是非常优秀的。但是在 C++20 推出之前，我们的 C++17 仍然是非常好的，它将改变很多人关于 C++ 已经落伍的旧印象。®
|
||
|
||
------
|
||
|
||
via: https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/
|
||
|
||
作者：[Thomas Claburn][a]
|
||
选题：[lujun9972](https://github.com/lujun9972)
|
||
译者：[qhwdw](https://github.com/qhwdw)
|
||
校对：[校对者ID](https://github.com/校对者ID)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]: http://www.theregister.co.uk/Author/3190
|
||
[1]: http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
|
||
[2]: https://www.vasamuseet.se/en/vasa-history/disaster
|
||
[3]: http://open-std.org/JTC1/SC22/WG21/
|
||
[4]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md
|
||
[5]: https://go.theregister.co.uk/tl/1755/shttps://continuouslifecycle.london/ |