Herb Sutter访谈：C++17尘埃落定

语言开发 C++

摘要： 继新的C++17标准在2017年四月完成之后，ISO C++委员会于上个月正式批准了该标准。这次，InfoQ有机会采访了Herb Sutter。多年以来，Sutter一直深度 参与ISO C++委员会的活动，并担任事实上的召集人。

作者： Sergio De Simone

正文：

继新的C++17标准在2017年四月完成之后，ISO C++委员会于上个月正式批准了该标准。InfoQ以往曾多次报道了新的C++标准。一旦标准中有新的主要特性得到批准，InfoQ就会及时地做详细报道。这次，InfoQ有机会采访了Herb Sutter。多年以来，Sutter一直深度 参与ISO C++委员会的活动，并担任事实上的召集人。

InfoQ：新的C++17标准中包含了大量的新特性，乍一看令人生畏。那么其中的主要亮点是什么？您认为哪些C++17特性最令开发人员感兴趣？

Herb Sutter：在我看来，在C++17的所有特性中，关键亮点是那些有助于简化该语言日常使用的特性。

回顾一下C++11刚推出时，它给出了大量的新特性，其中不乏一些巨大的亮点。但只有那些着眼于“日常细微之处”的特性才是最具影响力的，例如基于范围的for循环、auto、智能指针、lambdas、类成员初始化等。我们可以看见这些特性，并每天使用它们，让我们的代码更为整洁，更加安全。

现在我们推出了C++17，有人感兴趣的是并行STL等“大”特性，但是在我看来，日常编程中最受开发人员青睐的特性包括：结构化绑定（Structured Binding），例如：for (auto [key,value] : my_map) {…}；类模板参数规约（Class Template Argument Deduction），例如：用pair p{1, 2.0};替代pair<int, double>{1, 2.0};；与for循环体中一样，在if和switch语句内也可以初始化变量。这些特性减少了在编写C++语言代码时所需的一些仪式上的东西，使开发人员可以更简单地编写和维护代码。作为标准库中新的关键“词汇类型”，std::string_view和std::optional将会以函数参数和返回类型的形式广泛使用。这允许开发人员编写更简单的签名，例如：在字符串类型上可以用std::string_view替代模板化（Templatizing）；开发人员可在函数体内更多地用std::variant和std::any类型作为类成员，并内部使用。

小特性（尤其是那些聚集于简化开发的特性）的确可以提供巨大的改变。

InfoQ：Concepts无疑是C++中一个令人期盼已久的特性，但它并未进入C++17标准中。您能介绍一下背后的考量吗？

Sutter：Concepts进入C++标准只是一个时间上的问题，但是当前它还需要一段酝酿时间。

Concepts特性广受欢迎，该特性也在稳步推进中。不到一年前，在该特性在C++17中被冻结之前，我们将其以TS（技术规范，Technical Specification）发布，或可称为“Beta分支”，这样委员会的大多数成员可以从TS中获得体验，然后在最后期限之前尽快将其加入到标准之中。当我们在TS（或Beta版）中发布一个特性时，我们可以（也应当）花费一些时间收集对该特性的反馈，并在该特性将加入标准一事板上钉钉之前，做出一些重大的更改。一旦我们在C++ IS（国际标准，International Standard）中发布一个特性，余生即尘埃落定，几乎不可能再修改那些需做重大更改之处。

Concepts现在已在C++20草案中。在今年夏天召开的首次C++20标准制定会议上，Concepts成为在C++17发布之后首个添加到C++中的特性。令人关注的是，其中已经包含了一些基于TS得到经验而做出的改进。如果我们已经将它硬塞到C++17中，那么我们是很难做出这些改进的，或者说几乎不可能做出。

InfoQ：C++20关注的主要领域是什么？

Sutter：你可以通过查看我们已经发布的各个TS，很好地感受到在即将推出的C++标准中所给出的主要特性，最新的列表维护在isocpp.org/std/status处。大体上说，如果一个特性在截至之前已经包含在一个发布了一年以上的TS中，那么该特性就会成为下一个标准中的可能候选特性。对于C++20而言，其特性包含在2018年初左右发布的TS中。注意，我们从来不会不做更改地采纳一个TS，这表明了对较大的或实验性的特征先做TS处理的有用之处。

下面给出一些尚未加入C++17中，但目前已经的发布的主要TS：

Concepts TS：我们在做更改后，已经采纳了该TS中所有特性，唯一例外的是“简洁语法”（Terse Syntax），例如void f(MyConcept param) {…}。委员会投票强烈赞成，如果其中的技术问题得以解决，那么就实行该语法。我认为在随后的几次C++20草案会议中，非常有机会形成某种类型的决议。

Concurrency TS：事实上这是一组特性，将成为最佳选择（cherry-picked）。看上去应该添加的可能候选者包括原子的智能指针和锁。future<>扩展依赖于并行执行器（Concurrent Executor）建议，而该建议目前尚未完成，应该是在等待该建议得以解决后再做处理。

Library Fundamentals 2：这也是一组软件库特性。我们将会逐个特性考虑是否应归并到C++20草案中。

Ranges TS、Coroutines TS和Networking TS：这些TS刚刚通过最终批准，目前正在发布中，因此它们应该可在明年左右被考虑归并到C++20草案中。

注意，我并非预测这些特性将会加入到C++20中。我只是列出其中的一些主要候选者。有一两个大的特性尚未走到这一地步，例如静态反射（Static Reflection）。虽然它们进入到C++20中的机会渺茫，但这也在很大程度上取决于接下来的6到12个月中这些建议步入成熟的速度。当然，上面并非是对C++20潜在特性的完全列表。每个标准总是会包含很多不需要首先经由一个TS的更小改进。

InfoQ：在Rust、Swift和Go等一些新推出的语言中，您是否发现了一些有意思的或令人激动的特性？

Sutter：当然有。我非常有兴趣看到其它语言是如何探索和实验的。我认为，能看到一些新语言不断涌现并蓬勃发展，这是一个健康行业的重要标志。由于语言之间经常彼此借鉴，这将会改善每种语言的生态系统。

如果一门语言具有明确的意图是去替代另一门主要的现有语言，那么Swift无疑是一个很好的尝试（其将替代Objective-C）。对于一门新语言来说，如果正在开发和推广该语言的公司也正是主要使用被替换语言的公司，同时该公司也是拥有广泛使用现有语言的两个操作系统平台的公司，这几乎是一种最佳的情况。对于任何想要推广一种新语言的公司而言，在尝试对另一种语言的市场和开发商基础进行整体接收（或者说是替代）的过程中，这可能是最大借助力所在。很高兴能看到这样的过程，这也是非常具有启发性的。

InfoQ：您已经撰写了多本有影响的C++书籍。您现在是否在撰写新书？更宽泛地说，您当前主要关注哪些方面？

Sutter：我撰写文章和图书，是因为我很享受写出自己所学到的知识。分享这些新知识是颇具乐趣的，而且将它们教授给他人会强制我自己去深入地理解它们。一件事情只有能向别人解释清楚，才能确保你真正自如地掌握了它。

这些日子我更多地投身于新C++特性的定义工作中，而非学习新的事物。因此我这一段时间并没有写出多少文章和书籍，但是可能近期将会写出一些问答风格的博客文章。当前我所有的写作内容，几乎都会加入到标准建议以及“C++ Core Guidelines”中。

自两年前开始，我决定聚焦于一个长期的计划，即寻求那些使C++不仅更为强大而且更为易用的方法。通过简化实际C++代码和程序的编写和维护，这些方法将会使C++语言更为强大。我认为其中有很多可以做的事情，因此计划无限期地做下去。我做了多次实验尝试，找出其中起作用的工作，进而依次将这些工作标准化。目前为止，我已经将一个小特性推进到标准化过程中，即“<=>”比较操作符，我在报告“P0515”中做了详细的介绍，并已得到演进组的批准。它将在我们于11月召开的下一次会议中进入标准措辞审查。如果一切进展顺利，它有望尽快成为C++20草案的一部分。第二个特性稍大，目前依然更为实验性，并更具长期性。这就是我在报告“P0707”中给出的“metaclasses”特性。对此，我在CppCon 2017大会上也做了介绍，演讲可在YouTube上看到。

我希望委员会的各位同事也可以加入我的工作，专注于语言的简化。随处三三两两地独立添加小特性是一件十分有乐趣的事情，但是这导致了一些风险，即为语言增添的部分解决方案存在一些潜在的不一致之处。我认为，要简化开发人员实际编写的C++代码，我们还要做大量工作。找出实现目标的主要方法，其中重在对语言秉持广泛的和有原则的观点。正如我在一开始就提及的，在C++11、C++14中，我认为可能还包括C++17中，最具影响的特性可能并非一件“大事情”，而是那些让每日代码编写更简单的小事情。现在我们面前具有一个很大的机会，它特别关注语言的简单性，并非仅是做少量的清理，是做关键的简化。我谨慎乐观地认为，这将可为C++提供一些受到欢迎的大改进。Bjarne Stroustrup常常提及的著名论述就是：“C++内在是一种努力摆脱困境并追求更精巧、更安全的语言。如果我们可以从头开始的话，那么我们会给出仅有现在C++语言复杂性十分之一的语言”。当然这只是一个比喻，我们并不会实际这样去做（类似于从Objective-C转变为Swift）。但是我相信，我们是有方法实现大部分C++代码的简化，并且假以时日，语言本身也可以简化，虽然简化可能是一个递增的过程，并且是一个长期的过程。这样的工作即便仅推进了一半，我们也将会看到翻天覆地的改进。

人们有时会问：“为什么标准化不能加快？”。C++委员会知道，对于一门被450万程序员使用的语言，被多个关键行业所倚重，并跨越了从关键架构到终端应用的各种软件中的数十亿行代码，其中包括了一些其它语言的编译器，推进标准化无疑需要一些时间和精力。很显然，“快速推进并打破陈规”并不适用于此。我们在ISO C++中的工作就是推进这样一个巨大的生态系统，使其不会落后。尽管有一些我们想要追寻的目标看上去光彩夺目，但这可能偏离了我们的发展道路。对我们而言，“在系统有序的改进下实现推进”是更适用的宗旨。请记住，人们常会高估我们在两年内可实现的事情，并会低估我们在十年中所能实现的目标。我谨慎乐观地认为，如果我们继续发展C++，并在未来的十年中取得更好的发展，那么这一规则也将可适用于此。

Herb Sutter是软件开发的权威引领者，同时也是多本畅销书的作者，其中包括《Exceptional C++》和《C++编程规范》（C++ Coding Standards）等。Sutter曾担任ISO C++标准委员会主席达15年，并任Microsoft的软件架构师。在Microsoft工作期间，他领导了对C++/CLI、C++/CX、C++ AMP等语言扩展及其它一些技术的设计工作。

查看英文原文： C++17 is Here: Interview with Herb Sutter