mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
30f872aa07
@qhwdw @thecyanbird @Northurland @pityonline https://linux.cn/article-10202-1.html 大家辛苦了！
160 lines
15 KiB
Markdown
160 lines
15 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++ 的未来。
|
||
|
||
他明确表示，他用瓦萨号作为比喻并不是说他认为不断提升会带来毁灭。我们应该吸取瓦萨号的教训，构建一个坚实的基础，从错误中学习并对新版本做彻底的测试。
|
||
|
||
在瑞士<ruby>拉普斯威尔<rt>Rapperswill</rt></ruby>召开 C++ 标准化委员会会议之后，本月早些时候，Stroustrup 接受了 *The Register* 的采访，回答了有关 C++ 语言下一步发展方向的几个问题。（最新版是去年刚发布的 C++17；下一个版本是 C++20，预计于 2020 年发布。）
|
||
|
||
*Register：*在您的信件《想想瓦萨号！》中，您写道：
|
||
|
||
> 在 C++11 开始的基础建设尚未完成，而 C++17 基本没有在使基础更加稳固、规范和完整方面做出改善。相反，却增加了重要接口的复杂度（原文为 surface complexity，直译“表面复杂度”），让人们需要学习的特性数量越来越多。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 的<ruby>标准线程库<rt>standard thread library</rt></ruby>。它比起使用 POSIX 或直接使用 Windows 的 C API 来说更简单，并且更不易出错。
|
||
|
||
*Register：***您如何看待 C++ 现在的状况？**
|
||
|
||
*Stroustrup：*C++11 中作出了许多重大改进，并且我们在 C++14 上全面完成了改进工作。C++17 添加了相当多的新特性，但是没有提供对新技术的很多支持。C++20 目前看上去可能会成为一个重大改进版。编译器的状况非常好，标准库实现得也很优秀，非常接近最新的标准。C++17 现在已经可以使用，对于工具的支持正在逐步推进。已经有了许多第三方的库和好些新工具。然而，不幸的是，这些东西不太好找到。
|
||
|
||
我在《想想瓦萨号！》一文中所表达的担忧与标准化过程有关，对新东西的过度热情与完美主义的组合推迟了重大改进。“追求完美往往事与愿违”。在六月份拉普斯威尔的会议上有 160 人参与；在这样一个数量庞大且多样化的人群中很难取得一致意见。专家们也本来就有只为自己设计语言的倾向，这让他们不会时常在设计时考虑整个社区的需求。
|
||
|
||
*Register：***C++ 是否有一个理想的状态，或者与之相反，您只是为了程序员们的期望而努力，随时适应并且努力满足程序员们的需要？**
|
||
|
||
*Stroustrup：*二者都有。我很乐意看到 C++ 支持彻底保证<ruby>类型安全<rt>type-safe</rt></ruby>和<ruby>资源安全<rt>resource-safe</rt></ruby>的编程方式。这不应该通过限制适用性或增加性能损耗来实现，而是应该通过改进的表达能力和更好的性能来实现。通过让程序员使用更好的（和更易用的）语言工具可以达到这个目标，我们可以做到的。
|
||
|
||
终极目标不会马上实现，也不会单靠语言设计来实现。为了实现这一目标，我们需要改进语言特性、提供更好的库和静态分析，并且设立提升编程效率的规则。C++ 核心准则是我为了提升 C++ 代码质量而实行的广泛而长期的计划的一部分。
|
||
|
||
*Register：***目前 C++ 是否面临着可以预见的风险？如果有，它是以什么形式出现的？（如，迭代过于缓慢，新兴低级语言，等等……据您的观点来看，似乎是提出的提议过多。）**
|
||
|
||
*Stroustrup：*就是这样。今年我们已经收到了 400 篇文章。当然了，它们并不都是新提议。许多提议都与规范语言和标准库这一必需而乏味的工作相关，但是量大到难以管理。你可以在 [WG21 网站][6]上找到所有这些文章。
|
||
|
||
我写了《想想瓦萨号！》这封信作为一个呼吁，因为这种为了解决即刻需求（或者赶时髦）而不断增添语言特性，却对巩固语言基础（比如，改善<ruby>静态类型系统<rt>static type system</rt></ruby>）不管不问的倾向让我感到震惊。增加的任何新东西，无论它多小都会产生成本，比如实现、学习、工具升级。重大的特性改变能够改变我们对编程的想法，而它们才是我们必须关注的东西。
|
||
|
||
委员会已经设立了一个“指导小组”，这个小组由在语言、标准库、实现、以及工程实践领域中拥有不错履历的人组成。我是其中的成员之一。我们负责为重点领域写[一些关于发展方向、设计理念和建议重点发展领域的东西][7]。
|
||
|
||
对于 C++20，我们建议去关注：
|
||
|
||
* 概念
|
||
* 模块（适度地模块化并带来编译时的显著改进）
|
||
* Ranges（包括一些无限序列的扩展）
|
||
* 标准库中的网络概念
|
||
|
||
在拉普斯威尔会议之后，这些都有了实现的机会，虽然模块和网络化都不是会议的重点讨论对象。我是一个乐观主义者，并且委员会的成员们都非常努力。
|
||
|
||
我并不担心其它语言或新语言会取代它。我喜欢编程语言。如果一门新的语言提供了独一无二的、非常有用的东西，那它就是我们的榜样，我们可以向它学习。当然，每门语言本身都有一些问题。C++ 的许多问题都与它广泛的应用领域、大量的使用人群和过度的热情有关。大多数语言的社区都会有这样的问题。
|
||
|
||
*Register：***关于 C++ 您是否重新考虑过任何架构方面的决策？**
|
||
|
||
*Stroustrup：*当我着手规划新版本时，我经常反思原来的决策和设计。关于这些，可以看我的《编程的历史》论文第 [1][8]、[2][9] 部分。
|
||
|
||
并没有让我觉得很后悔的重大决策。如果我必须重新做一次，我觉得和以前做的不会有太大的不同。
|
||
|
||
与以前一样，能够直接处理硬件加上零开销的抽象是设计的指导思想。使用<ruby>构造函数<rt>constructor</rt></ruby>和<ruby>析构函数<rt>destructor</rt></ruby>去处理资源是关键（<ruby>资源获取即初始化<rt>Resource Acquisition Is Initialization</rt><ruby>，RAII）；<ruby>标准模板库<rt>Standard Template Library</rt></ruby>（STL） 就是解释 C++ 库能够做什么的一个很好的例子。
|
||
|
||
*Register：***在 2011 年被采纳的每三年发布一个新版本的节奏是否仍然有效？我之所以这样问是因为 Java 已经决定更快地迭代。**
|
||
|
||
*Stroustrup：*我认为 C++20 将会按时发布（就像 C++14 和 C++17 那样），并且主流的编译器也会立即采用它。我也希望 C++20 基于 C++17 能有重大的改进。
|
||
|
||
对于其它语言如何管理它们的版本，我并不十分关心。C++ 是由一个遵循 ISO 规则的委员会来管理的，而不是由某个大公司或某种“<ruby>终生的仁慈独裁者<rt>Beneficial Dictator Of Life</rt></ruby>（BDOL）”来管理。这一点不会改变。C++ 每三年发布一次的周期在 ISO 标准中是一个引人注目的创举。通常而言，周期应该是 5 或 10 年。
|
||
|
||
*Register：***在您的信中您写道：**
|
||
|
||
> 我们需要一个能够被“普通程序员”使用的，条理还算清楚的编程语言。他们主要关心的是，能否按时高质量地交付他们的应用程序。
|
||
|
||
改进语言能够解决这个问题吗？或者，我们还需要更容易获得的工具和教育支持？
|
||
|
||
*Stroustrup：*我尽力宣传我关于 C++ 的实质和使用方式的[理念][10]，并且我鼓励其他人也和我采取相同的行动。
|
||
|
||
特别是，我鼓励讲师和作者们向 C++ 程序员们提出有用的建议，而不是去示范复杂的示例和技术来展示他们自己有多高明。我在 2017 年的 CppCon 大会上的演讲主题就是“学习和传授 C++”，并且也指出，我们需要更好的工具。
|
||
|
||
我在演讲中提到了构建技术支持和包管理器，这些历来都是 C++ 的弱项。标准化委员会现在有一个工具研究小组，或许不久的将来也会组建一个教育研究小组。
|
||
|
||
C++ 的社区以前是十分无组织性的，但是在过去的五年里，为了满足社区对新闻和技术支持的需要，出现了很多集会和博客。CppCon、isocpp.org、以及 Meeting++ 就是一些例子。
|
||
|
||
在一个庞大的委员会中做语言标准设计是很困难的。但是，对于所有的大型项目来说，委员会又是必不可少的。我很忧虑，但是关注它们并且面对问题是成功的必要条件。
|
||
|
||
*Register：***您如何看待 C++ 社区的流程？在沟通和决策方面你希望看到哪些变化？**
|
||
|
||
*Stroustrup：*C++ 并没有企业管理一般的“社区流程”；它所遵循的是 ISO 标准流程。我们不能对 ISO 的条例做大的改变。理想的情况是，我们设立一个小型的、全职的“秘书处”来做最终决策和方向管理，但这种理想情况是不会出现的。相反，我们有成百上千的人在线讨论，大约有 160 人在技术问题上进行投票，大约有 70 组织和 11 个国家的人在最终提议上正式投票。这样很混乱，但是有些时候它的确能发挥作用。
|
||
|
||
*Register：***在最后，您认为那些即将推出的 C++ 特性中，对 C++ 用户最有帮助的是哪些？**
|
||
|
||
*Stroustrup：*
|
||
|
||
* 那些能让编程显著变简单的概念。
|
||
* <ruby>并行算法<rt>Parallel algorithms</rt></ruby> —— 如果要使用现代硬件的并发特性的话，这方法再简单不过了。
|
||
* <ruby>协程<rt>Coroutines</rt></ruby>，如果委员会能够确定在 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)
|
||
校对：[thecyanbird](https://github.com/thecyanbird)、[Northurland](https://github.com/Northurland)、[pityonline](https://github.com/pityonline)
|
||
|
||
本文由 [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/
|
||
[6]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
|
||
[7]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0939r0.pdf
|
||
[8]: http://www.stroustrup.com/hopl-almost-final.pdf
|
||
[9]: http://www.stroustrup.com/hopl2.pdf
|
||
[10]: http://www.stroustrup.com/papers.html
|