对 C++ 的忧虑?C++ 创始人警告:关于 C++ 的某些未来计划十分危险

对 C++ 的忧虑?C++ 创始人警告:关于 C++ 的某些未来计划十分危险

今年早些时候,我们对 Bjarne Stroustrup 进行了采访。他是 C++ 语言的创始人,摩根士丹利技术部门的董事总经理,美国哥伦比亚大学计算机科学的客座教授。他写了一封信,请那些关注编程语言进展的人去“想想瓦萨号!”

这句话对于丹麦人来说,毫无疑问,很容易理解。而那些对于 17 世纪的斯堪的纳维亚历史了解不多的人,还需要详细说明一下。瓦萨号是一艘瑞典军舰,由国王 Gustavus Adolphus 定做。它是当时波罗的海国家中最强大的军舰,但在 1628 年 8 月 10 日首航没几分钟之后就沉没了。

巨大的瓦萨号有一个难以解决的设计缺陷:头重脚轻,以至于它被一阵狂风刮翻了。通过援引这艘沉船的历史,Stroustrup 警示了 C++ 所面临的风险 —— 现在越来越多的特性被添加到了 C++ 中。

我们现在已经发现了好些能导致头重脚轻的特性。Stroustrup 在他的信中引用了 43 个提议。他认为那些参与 C++ 语言 ISO 标准演进的人(即所谓的 WG21 小组)正在努力推进语言发展,但成员们的努力方向却并不一致。

在他的信中,他写道:

分开来看,许多提议都很有道理。但将它们综合到一起,这些提议是很愚蠢的,将危害 C++ 的未来。

他明确表示,他用瓦萨号作为比喻并不是说他认为不断提升会带来毁灭。我们应该吸取瓦萨号的教训,构建一个坚实的基础,从错误中学习并对新版本做彻底的测试。

在瑞士 拉普斯威尔 Rapperswill 召开 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++ 核心准则作为实现上述目标的一个辅助。

此外,我的“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 的 标准线程库 standard thread library 。它比起使用 POSIX 或直接使用 Windows 的 C API 来说更简单,并且更不易出错。

*Register:*您如何看待 C++ 现在的状况?

*Stroustrup:*C++11 中作出了许多重大改进,并且我们在 C++14 上全面完成了改进工作。C++17 添加了相当多的新特性,但是没有提供对新技术的很多支持。C++20 目前看上去可能会成为一个重大改进版。编译器的状况非常好,标准库实现得也很优秀,非常接近最新的标准。C++17 现在已经可以使用,对于工具的支持正在逐步推进。已经有了许多第三方的库和好些新工具。然而,不幸的是,这些东西不太好找到。

我在《想想瓦萨号!》一文中所表达的担忧与标准化过程有关,对新东西的过度热情与完美主义的组合推迟了重大改进。“追求完美往往事与愿违”。在六月份拉普斯威尔的会议上有 160 人参与;在这样一个数量庞大且多样化的人群中很难取得一致意见。专家们也本来就有只为自己设计语言的倾向,这让他们不会时常在设计时考虑整个社区的需求。

*Register:*C++ 是否有一个理想的状态,或者与之相反,您只是为了程序员们的期望而努力,随时适应并且努力满足程序员们的需要?

*Stroustrup:*二者都有。我很乐意看到 C++ 支持彻底保证 类型安全 type-safe 和 资源安全 resource-safe 的编程方式。这不应该通过限制适用性或增加性能损耗来实现,而是应该通过改进的表达能力和更好的性能来实现。通过让程序员使用更好的(和更易用的)语言工具可以达到这个目标,我们可以做到的。

终极目标不会马上实现,也不会单靠语言设计来实现。为了实现这一目标,我们需要改进语言特性、提供更好的库和静态分析,并且设立提升编程效率的规则。C++ 核心准则是我为了提升 C++ 代码质量而实行的广泛而长期的计划的一部分。

*Register:*目前 C++ 是否面临着可以预见的风险?如果有,它是以什么形式出现的?(如,迭代过于缓慢,新兴低级语言,等等……据您的观点来看,似乎是提出的提议过多。)

*Stroustrup:*就是这样。今年我们已经收到了 400 篇文章。当然了,它们并不都是新提议。许多提议都与规范语言和标准库这一必需而乏味的工作相关,但是量大到难以管理。你可以在 WG21 网站上找到所有这些文章。

我写了《想想瓦萨号!》这封信作为一个呼吁,因为这种为了解决即刻需求(或者赶时髦)而不断增添语言特性,却对巩固语言基础(比如,改善 静态类型系统 static type system )不管不问的倾向让我感到震惊。增加的任何新东西,无论它多小都会产生成本,比如实现、学习、工具升级。重大的特性改变能够改变我们对编程的想法,而它们才是我们必须关注的东西。

委员会已经设立了一个“指导小组”,这个小组由在语言、标准库、实现、以及工程实践领域中拥有不错履历的人组成。我是其中的成员之一。我们负责为重点领域写一些关于发展方向、设计理念和建议重点发展领域的东西

对于 C++20,我们建议去关注:

  • 概念
  • 模块(适度地模块化并带来编译时的显著改进)
  • Ranges(包括一些无限序列的扩展)
  • 标准库中的网络概念

在拉普斯威尔会议之后,这些都有了实现的机会,虽然模块和网络化都不是会议的重点讨论对象。我是一个乐观主义者,并且委员会的成员们都非常努力。

我并不担心其它语言或新语言会取代它。我喜欢编程语言。如果一门新的语言提供了独一无二的、非常有用的东西,那它就是我们的榜样,我们可以向它学习。当然,每门语言本身都有一些问题。C++ 的许多问题都与它广泛的应用领域、大量的使用人群和过度的热情有关。大多数语言的社区都会有这样的问题。

*Register:*关于 C++ 您是否重新考虑过任何架构方面的决策?

*Stroustrup:*当我着手规划新版本时,我经常反思原来的决策和设计。关于这些,可以看我的《编程的历史》论文第 12 部分。

并没有让我觉得很后悔的重大决策。如果我必须重新做一次,我觉得和以前做的不会有太大的不同。

与以前一样,能够直接处理硬件加上零开销的抽象是设计的指导思想。使用 构造函数 constructor 和 析构函数 destructor 去处理资源是关键( 资源获取即初始化 Resource Acquisition Is Initialization ,RAII); 标准模板库 Standard Template Library (STL) 就是解释 C++ 库能够做什么的一个很好的例子。

*Register:*在 2011 年被采纳的每三年发布一个新版本的节奏是否仍然有效?我之所以这样问是因为 Java 已经决定更快地迭代。

*Stroustrup:*我认为 C++20 将会按时发布(就像 C++14 和 C++17 那样),并且主流的编译器也会立即采用它。我也希望 C++20 基于 C++17 能有重大的改进。

对于其它语言如何管理它们的版本,我并不十分关心。C++ 是由一个遵循 ISO 规则的委员会来管理的,而不是由某个大公司或某种“ 终生的仁慈独裁者 Beneficial Dictator Of Life (BDOL)”来管理。这一点不会改变。C++ 每三年发布一次的周期在 ISO 标准中是一个引人注目的创举。通常而言,周期应该是 5 或 10 年。

*Register:*在您的信中您写道:

我们需要一个能够被“普通程序员”使用的,条理还算清楚的编程语言。他们主要关心的是,能否按时高质量地交付他们的应用程序。

改进语言能够解决这个问题吗?或者,我们还需要更容易获得的工具和教育支持?

*Stroustrup:*我尽力宣传我关于 C++ 的实质和使用方式的理念,并且我鼓励其他人也和我采取相同的行动。

特别是,我鼓励讲师和作者们向 C++ 程序员们提出有用的建议,而不是去示范复杂的示例和技术来展示他们自己有多高明。我在 2017 年的 CppCon 大会上的演讲主题就是“学习和传授 C++”,并且也指出,我们需要更好的工具。

我在演讲中提到了构建技术支持和包管理器,这些历来都是 C++ 的弱项。标准化委员会现在有一个工具研究小组,或许不久的将来也会组建一个教育研究小组。

C++ 的社区以前是十分无组织性的,但是在过去的五年里,为了满足社区对新闻和技术支持的需要,出现了很多集会和博客。CppCon、isocpp.org、以及 Meeting++ 就是一些例子。

在一个庞大的委员会中做语言标准设计是很困难的。但是,对于所有的大型项目来说,委员会又是必不可少的。我很忧虑,但是关注它们并且面对问题是成功的必要条件。

*Register:*您如何看待 C++ 社区的流程?在沟通和决策方面你希望看到哪些变化?

*Stroustrup:*C++ 并没有企业管理一般的“社区流程”;它所遵循的是 ISO 标准流程。我们不能对 ISO 的条例做大的改变。理想的情况是,我们设立一个小型的、全职的“秘书处”来做最终决策和方向管理,但这种理想情况是不会出现的。相反,我们有成百上千的人在线讨论,大约有 160 人在技术问题上进行投票,大约有 70 组织和 11 个国家的人在最终提议上正式投票。这样很混乱,但是有些时候它的确能发挥作用。

*Register:*在最后,您认为那些即将推出的 C++ 特性中,对 C++ 用户最有帮助的是哪些?

Stroustrup:

  • 那些能让编程显著变简单的概念。
  • 并行算法 Parallel algorithms —— 如果要使用现代硬件的并发特性的话,这方法再简单不过了。
  • 协程 Coroutines ,如果委员会能够确定在 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 选题:lujun9972 译者:qhwdw 校对:thecyanbirdNorthurlandpityonline

本文由 LCTT 原创编译,Linux中国 荣誉推出