mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-23 21:20:42 +08:00
PRF:20180618 What-s all the C Plus Fuss- Bjarne Stroustrup warns of dangerous future plans for his C.md
格式调整
This commit is contained in:
Xingyu.Wang
parent
2f4e603711
commit
76fdc01ed5
@ -1,4 +1,5 @@
|
||||
# 对 C++ 的忧虑？Bjarne Stroustrup 警告，关于 C++ 的某些未来计划十分危险
|
||||
对 C++ 的忧虑？Bjarne Stroustrup 警告，关于 C++ 的某些未来计划十分危险
|
||||
======
|
||||
|
||||
|
||||
|
||||
@ -18,13 +19,13 @@
|
||||
|
||||
在瑞士<ruby>拉普斯威尔<rt>Rapperswill</rt></ruby>召开 C++ 标准化委员会会议之后，本月早些时候，Stroustrup 接受了 *The Register* 的采访，回答了有关 C++ 语言下一步发展方向的几个问题。（最新版是去年刚发布的 C++17；下一个版本是 C++20，预计于 2020 年发布。）
|
||||
|
||||
**<i>Register：</i>在您的信件《想想瓦萨号！》中，您写道：**
|
||||
*Register：*在您的信件《想想瓦萨号！》中，您写道：
|
||||
|
||||
> 在 C++11 开始的基础建设尚未完成，而 C++17 基本没有在使基础更加稳固、规范和完整方面做出改善。相反，却增加了重要接口的复杂度（原文为 surface complexity，直译“表面复杂度”），让人们需要学习的特性数量越来越多。C++ 可能在这种不成熟的提议的重压之下崩溃。我们不应该花费大量的时间为专家级用户们（比如我们自己）去创建越来越复杂的东西。~~（还要考虑普通用户的学习曲线，越复杂的东西越不易普及。）~~
|
||||
|
||||
**对新人来说，C++ 过难了吗？如果是这样，您认为怎样的特性让新人更易理解？**
|
||||
|
||||
<b><i>Stroustrup：</i></b>C++ 的有些东西对于新人来说确实很具有挑战性。
|
||||
*Stroustrup：*C++ 的有些东西对于新人来说确实很具有挑战性。
|
||||
|
||||
另一方面而言，C++ 中有些东西对于新人来说，比起 C 或上世纪九十年代的 C++ 更容易理解了。而难点是让大型社区专注于这些部分，并且帮助新手和非专业的 C++ 用户去规避那些对高级库实现提供支持的部分。
|
||||
|
||||
@ -50,21 +51,21 @@ for (int i=0; i<MAX; i++) ++v[i]; // increment each element of the array v
|
||||
|
||||
另一个例子是 C++11 的<ruby>标准线程库<rt>standard thread library</rt></ruby>。它比起使用 POSIX 或直接使用 Windows 的 C API 来说更简单，并且更不易出错。
|
||||
|
||||
**<i>Register：</i>您如何看待 C++ 现在的状况？**
|
||||
*Register：***您如何看待 C++ 现在的状况？**
|
||||
|
||||
<b><i>Stroustrup：</i></b>C++11 中作出了许多重大改进，并且我们在 C++14 上全面完成了改进工作。C++17 添加了相当多的新特性，但是没有提供对新技术的很多支持。C++20 目前看上去可能会成为一个重大改进版。编译器的状况非常好，标准库实现得也很优秀，非常接近最新的标准。C++17 现在已经可以使用，对于工具的支持正在逐步推进。已经有了许多第三方的库和好些新工具。然而，不幸的是，这些东西不太好找到。
|
||||
*Stroustrup：*C++11 中作出了许多重大改进，并且我们在 C++14 上全面完成了改进工作。C++17 添加了相当多的新特性，但是没有提供对新技术的很多支持。C++20 目前看上去可能会成为一个重大改进版。编译器的状况非常好，标准库实现得也很优秀，非常接近最新的标准。C++17 现在已经可以使用，对于工具的支持正在逐步推进。已经有了许多第三方的库和好些新工具。然而，不幸的是，这些东西不太好找到。
|
||||
|
||||
我在《想想瓦萨号！》一文中所表达的担忧与标准化过程有关，对新东西的过度热情与完美主义的组合推迟了重大改进。“追求完美往往事与愿违”。在六月份拉普斯威尔的会议上有 160 人参与；在这样一个数量庞大且多样化的人群中很难取得一致意见。专家们也本来就有只为自己设计语言的倾向，这让他们不会时常在设计时考虑整个社区的需求。
|
||||
|
||||
**<i>Register：</i>C++ 是否有一个理想的状态，或者与之相反，您只是为了程序员们的期望而努力，随时适应并且努力满足程序员们的需要？**
|
||||
*Register：***C++ 是否有一个理想的状态，或者与之相反，您只是为了程序员们的期望而努力，随时适应并且努力满足程序员们的需要？**
|
||||
|
||||
<b><i>Stroustrup：</i></b>二者都有。我很乐意看到 C++ 支持彻底保证<ruby>类型安全<rt>type-safe</rt></ruby>和<ruby>资源安全<rt>resource-safe</rt></ruby>的编程方式。这不应该通过限制适用性或增加性能损耗来实现，而是应该通过改进的表达能力和更好的性能来实现。通过让程序员使用更好的（和更易用的）语言工具可以达到这个目标，我们可以做到的。
|
||||
*Stroustrup：*二者都有。我很乐意看到 C++ 支持彻底保证<ruby>类型安全<rt>type-safe</rt></ruby>和<ruby>资源安全<rt>resource-safe</rt></ruby>的编程方式。这不应该通过限制适用性或增加性能损耗来实现，而是应该通过改进的表达能力和更好的性能来实现。通过让程序员使用更好的（和更易用的）语言工具可以达到这个目标，我们可以做到的。
|
||||
|
||||
终极目标不会马上实现，也不会单靠语言设计来实现。为了实现这一目标，我们需要改进语言特性、提供更好的库和静态分析，并且设立提升编程效率的规则。C++ 核心准则是我为了提升 C++ 代码质量而实行的广泛而长期的计划的一部分。
|
||||
|
||||
**<i>Register：</i>目前 C++ 是否面临着可以预见的风险？如果有，它是以什么形式出现的？（如，迭代过于缓慢，新兴低级语言，等等……据您的观点来看，似乎是提出的提议过多。）**
|
||||
*Register：***目前 C++ 是否面临着可以预见的风险？如果有，它是以什么形式出现的？（如，迭代过于缓慢，新兴低级语言，等等……据您的观点来看，似乎是提出的提议过多。）**
|
||||
|
||||
<b><i>Stroustrup：</i></b>就是这样。今年我们已经收到了 400 篇文章。当然了，它们并不都是新提议。许多提议都与规范语言和标准库这一必需而乏味的工作相关，但是量大到难以管理。你可以在 [WG21 网站][6]上找到所有这些文章。
|
||||
*Stroustrup：*就是这样。今年我们已经收到了 400 篇文章。当然了，它们并不都是新提议。许多提议都与规范语言和标准库这一必需而乏味的工作相关，但是量大到难以管理。你可以在 [WG21 网站][6]上找到所有这些文章。
|
||||
|
||||
我写了《想想瓦萨号！》这封信作为一个呼吁，因为这种为了解决即刻需求（或者赶时髦）而不断增添语言特性，却对巩固语言基础（比如，改善<ruby>静态类型系统<rt>static type system</rt></ruby>）不管不问的倾向让我感到震惊。增加的任何新东西，无论它多小都会产生成本，比如实现、学习、工具升级。重大的特性改变能够改变我们对编程的想法，而它们才是我们必须关注的东西。
|
||||
|
||||
@ -81,27 +82,27 @@ for (int i=0; i<MAX; i++) ++v[i]; // increment each element of the array v
|
||||
|
||||
我并不担心其它语言或新语言会取代它。我喜欢编程语言。如果一门新的语言提供了独一无二的、非常有用的东西，那它就是我们的榜样，我们可以向它学习。当然，每门语言本身都有一些问题。C++ 的许多问题都与它广泛的应用领域、大量的使用人群和过度的热情有关。大多数语言的社区都会有这样的问题。
|
||||
|
||||
**<i>Register：</i>关于 C++ 您是否重新考虑过任何架构方面的决策？**
|
||||
*Register：***关于 C++ 您是否重新考虑过任何架构方面的决策？**
|
||||
|
||||
<b><i>Stroustrup：</i></b>当我着手规划新版本时，我经常反思原来的决策和设计。关于这些，可以看我的《编程的历史》论文第 [1][8]、[2][9] 部分。
|
||||
*Stroustrup：*当我着手规划新版本时，我经常反思原来的决策和设计。关于这些，可以看我的《编程的历史》论文第 [1][8]、[2][9] 部分。
|
||||
|
||||
并没有让我觉得很后悔的重大决策。如果我必须重新做一次，我觉得和以前做的不会有太大的不同。
|
||||
|
||||
与以前一样，能够直接处理硬件加上零开销的抽象是设计的指导思想。使用<ruby>构造函数<rt>constructor</rt></ruby>和<ruby>析构函数<rt>destructor</rt></ruby>去处理资源是关键（<ruby>RAII<rt>Resource Acquisition Is Initialization</rt><ruby>）；<ruby>STL<rt>Standard Template Library</rt></ruby> 就是解释 C++ 库能够做什么的一个很好的例子。
|
||||
与以前一样，能够直接处理硬件加上零开销的抽象是设计的指导思想。使用<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++ 库能够做什么的一个很好的例子。
|
||||
|
||||
**<i>Register：</i>在 2011 年被采纳的每三年发布一个新版本的节奏是否仍然有效？我之所以这样问是因为 Java 已经决定更快地迭代。**
|
||||
*Register：***在 2011 年被采纳的每三年发布一个新版本的节奏是否仍然有效？我之所以这样问是因为 Java 已经决定更快地迭代。**
|
||||
|
||||
<b><i>Stroustrup：</i></b>我认为 C++20 将会按时发布（就像 C++14 和 C++17 那样），并且主流的编译器也会立即采用它。我也希望 C++20 基于 C++17 能有重大的改进。
|
||||
*Stroustrup：*我认为 C++20 将会按时发布（就像 C++14 和 C++17 那样），并且主流的编译器也会立即采用它。我也希望 C++20 基于 C++17 能有重大的改进。
|
||||
|
||||
对于其它语言如何管理它们的版本，我并不十分关心。C++ 是由一个遵循 ISO 规则的委员会来管理的，而不是由某个大公司或某种“<ruby>终生的仁慈独裁者<rt>Beneficial Dictator Of Life</rt></ruby>”来管理。这一点不会改变。C++ 每三年发布一次的周期在 ISO 标准中是一个引人注目的创举。通常而言，周期应该是 5 或 10 年。
|
||||
对于其它语言如何管理它们的版本，我并不十分关心。C++ 是由一个遵循 ISO 规则的委员会来管理的，而不是由某个大公司或某种“<ruby>终生的仁慈独裁者<rt>Beneficial Dictator Of Life</rt></ruby>（BDOL）”来管理。这一点不会改变。C++ 每三年发布一次的周期在 ISO 标准中是一个引人注目的创举。通常而言，周期应该是 5 或 10 年。
|
||||
|
||||
**<i>Register：</i>在您的信中您写道：**
|
||||
*Register：***在您的信中您写道：**
|
||||
|
||||
> 我们需要一个能够被“普通程序员”使用的，条理还算清楚的编程语言。他们主要关心的是，能否按时高质量地交付他们的应用程序。
|
||||
|
||||
改进语言能够解决这个问题吗？或者，我们还需要更容易获得的工具和教育支持？
|
||||
|
||||
<b><i>Stroustrup：</i></b>我尽力宣传我关于 C++ 的实质和使用方式的[理念][10]，并且我鼓励其他人也和我采取相同的行动。
|
||||
*Stroustrup：*我尽力宣传我关于 C++ 的实质和使用方式的[理念][10]，并且我鼓励其他人也和我采取相同的行动。
|
||||
|
||||
特别是，我鼓励讲师和作者们向 C++ 程序员们提出有用的建议，而不是去示范复杂的示例和技术来展示他们自己有多高明。我在 2017 年的 CppCon 大会上的演讲主题就是“学习和传授 C++”，并且也指出，我们需要更好的工具。
|
||||
|
||||
@ -111,13 +112,13 @@ C++ 的社区以前是十分无组织性的，但是在过去的五年里，为
|
||||
|
||||
在一个庞大的委员会中做语言标准设计是很困难的。但是，对于所有的大型项目来说，委员会又是必不可少的。我很忧虑，但是关注它们并且面对问题是成功的必要条件。
|
||||
|
||||
**<i>Register：</i>您如何看待 C++ 社区的流程？在沟通和决策方面你希望看到哪些变化？**
|
||||
*Register：***您如何看待 C++ 社区的流程？在沟通和决策方面你希望看到哪些变化？**
|
||||
|
||||
<b><i>Stroustrup：</i></b>C++ 并没有企业管理一般的“社区流程”；它所遵循的是 ISO 标准流程。我们不能对 ISO 的条例做大的改变。理想的情况是，我们设立一个小型的、全职的“秘书处”来做最终决策和方向管理，但这种理想情况是不会出现的。相反，我们有成百上千的人在线讨论，大约有 160 人在技术问题上进行投票，大约有 70 组织和 11 个国家的人在最终提议上正式投票。这样很混乱，但是有些时候它的确能发挥作用。
|
||||
*Stroustrup：*C++ 并没有企业管理一般的“社区流程”；它所遵循的是 ISO 标准流程。我们不能对 ISO 的条例做大的改变。理想的情况是，我们设立一个小型的、全职的“秘书处”来做最终决策和方向管理，但这种理想情况是不会出现的。相反，我们有成百上千的人在线讨论，大约有 160 人在技术问题上进行投票，大约有 70 组织和 11 个国家的人在最终提议上正式投票。这样很混乱，但是有些时候它的确能发挥作用。
|
||||
|
||||
**<i>Register：</i>在最后，您认为那些即将推出的 C++ 特性中，对 C++ 用户最有帮助的是哪些？**
|
||||
*Register：***在最后，您认为那些即将推出的 C++ 特性中，对 C++ 用户最有帮助的是哪些？**
|
||||
|
||||
**<i>Stroustrup：</i>**
|
||||
*Stroustrup：*
|
||||
|
||||
* 那些能让编程显著变简单的概念。
|
||||
* <ruby>并行算法<rt>Parallel algorithms</rt></ruby> —— 如果要使用现代硬件的并发特性的话，这方法再简单不过了。
|
||||
@ -130,9 +131,9 @@ C++ 的社区以前是十分无组织性的，但是在过去的五年里，为
|
||||
* Contracts（运行时检查的先决条件、后置条件、和断言）可能对许多人都非常重要。
|
||||
* date 和 time-zone 支持库可能对许多人（行业）非常重要。
|
||||
|
||||
**<i>Register：</i>您还有想对读者们说的话吗？**
|
||||
*Register：***您还有想对读者们说的话吗？**
|
||||
|
||||
<b><i>Stroustrup：</i></b>如果 C++ 标准化委员会能够专注于重大问题，去解决重大问题，那么 C++20 将会非常优秀。但是在 C++20 推出之前，我们还有 C++17；无论如何，它仍然远超许多人对 C++ 的旧印象。®
|
||||
*Stroustrup：*如果 C++ 标准化委员会能够专注于重大问题，去解决重大问题，那么 C++20 将会非常优秀。但是在 C++20 推出之前，我们还有 C++17；无论如何，它仍然远超许多人对 C++ 的旧印象。®
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user