与C++之父Bjarne Stroustrup面对面 | 活动回顾(含PPT)-演道网

| 分享嘉宾:Bjarne Stroustrup / C++之父

| 图文整理编辑:博览网Boolan

特别感谢C++社区的译者们(排名不分先后 ):

王献、张旋、刁寿钧 、侯文彪、贺丽、李鹏飞、张斌、周梦伊、timminn

以下内容精选自Boolan 2014线下俱乐部活动:《与C++之父Bjarne Stroustrup面对面》本文原创,转载请注明出处。

另外,C++之父Bjarne Stroustrup作为“2016 C++及系统软件技术大会”的重磅嘉宾,将在今年10月底的C++大会中带来《What C++ Is and What It Will Become》的话题演讲(主题以最终公布的为准)

戳底部“阅读原文”报名10.28-10.29的C++大会2016

【文末彩蛋】C++大会完整PPT资料、及更多大咖直播在本文最末领取~

本文由“135编辑器”提供技术支持

先附上活动的现场照 –>

以下为正文内容

建忠(博览网-Boolan.com创始人)听到我在中国后,可以说是在最后关头安排了这次活动。前两周我一直在各地出差,我的声音听上去可能有些疲倦,因为今天是我出差的最后一天,明天我将飞回纽约。

今天晚上我会花30-40分钟简单介绍一下现代C++:C++11和C++14,然后进行一个较长的问答环节。因为我不打算对细节做过多的讲解,我也不知道什么细节才是你们最想知道的,所以我宁愿后面花很长的时间来回答你们的问题。我会谈一些C++标准。

刚才说了,我现在在纽约的摩根士丹利工作,这是为什么我会在中国和摩根士丹利的中国员工进行交流,也去一些大学做演说。

如果你想知道更多关于摩根士丹利的细节,他们平时做什么,这里有和我一起来的两位同事,请起身让各位知道你们是谁。所以如果你想知道任何关于上海摩根士丹利的事情,可与这两位交流。

我同时也是哥伦比亚的客座教授,尽管我辞掉了Texas A&M的教职,但在校方坚持下,我现在还算是一名教授。

好的,接下来我会简单介绍:

  • 我们希望从编程语言中获得什么,编程语言在开发环境中扮演者什么角色

  • 一个使用C++11的简单例子

  • 然后我会过一遍C++11/C++14中的特性

  • 最后进入问答环节

这次演讲不可能涵盖C++11/14 中所有的东西,这不是半个小时的演讲能做到的。如果你有问题的话,可以翻阅一些资料,或许可以得到解答。

当我们讨论编程语言时,人们往往被编程语言的特性吸引,好像这是唯一重要的东西。我们并不这样认为,我们从不认为语言特性是最有意思的部分。

我们关心的是如何构建系统。一个较好的系统应该具备这些要素:吞吐量大、延迟小、bug少、可维护性高、开发速度快,等等。这些才是我们真正想要的。编程语言应该尽力去实现这些目标。如果我们太过关注于怎么写一个循环,或者指针应该怎样表示,或者诸如此类的问题,我们就会忽视那些更重要的东西。显然,不能这么做。

上面这些才是我们应该尽力去做到的。编程语言只是“工具链”的一环,如果我们手里有两种编程语言,它们在以上方面都很好,但某个更优的“工具链”,那还是能分出优劣来。如果对于正在搭建的应用或者系统,没有使用正确的“工具链”的话,问题也会随之而来,所以我们必须注意这些问题。

另外,我们要改善语言,但不是为了改变而改变。我们应该清楚作出改善改变的原因,以及需要达到什么样效果。当我在思考语言,想它的用处的时候,我总是在思考:“Bug 是从哪儿来的?Bug 隐藏在什么地方?我如何才能避免犯错?又该如何去发现已经犯下的错误?”

而这很大程度上和简化代码有关。作为一门成熟的编程语言,我们现在的一大问题是:很多人在90年代按照当时的风格编写了C++代码。这不算错误,但是,现如今仍然有人按照90年代的方式写代码,这让我觉得很懊恼,因为我们明明可以把代码写得更好。我们应该思考如何才能做的更好,以达到最初的目标,并且思考如何摆脱旧代码,消除其中存在的问题。

下面我将会举一个例子,也是唯一一个例子,展示如何用C++11 来简化代码。

三周前,我从一个朋友那拿了一段代码,这是现实中的代码。这段代码取自一个发布了8年之久的产品中。这段代码写得很好,写代码的人也是熟手。这段代码没有什么根本性错误,我得强调一下。

它大概是这样的:他们想要从头遍历一个容器(额,那个声明应该放这里,抱歉…),寻找一个特定的模式,如果符合该模式,进入if条件句执行代码,否则转入其他语句。

通过C++11,我们可以简化这部分操作。我们仅仅定义一个迭代器,指向容器开头,每次迭代地址加1,直到容器末尾,寻找符合条件的模式。

这段代码中有两点需要注意:

代码变短了,因为不需要写出迭代器的类型。不清楚你们是否喜欢编写这么冗长的代码,但我肯定不会。这样写太麻烦了,应该避免!

此外,由于我们将迭代器变量的定义放到for中,所以cit的生命周期被局限在for循环里,它也本该如此。在那段实际代码中,我们必须非常注意变量cit不能在for循环体外面被访问。如果万一真的被用到,我们必须知道为什么,因为cit已指向容器末尾。这是一个简单的循环,它正确而简短,不错。

他们看了一会儿代码后意识到:在C++11中,我们不仅仅有auto,我们有range-for语句,专为编写这种最简单的循环,即对于 v 中的每一个 x,尝试匹配某个模式,然后做一些事情。他们如此简化了代码。所以在C++11中你可以用range-for语法来描述一个这种简单循环。

对于简化后的代码,我们知道在 for 循环体中是不可以修改循环变量的,这里也没有可以修改的循环变量。但在之前的代码中,要看出这只是一个普通的循环遍历确实有点困难。我不是故意要制造Bug,但却由于失误造成了Bug。这Bug不在我朋友发给我的代码中,但不管怎样,看这里。

“从头到尾遍历一个容器”的意思在这段代码中显然不是那么直观,但在这段被简化代码中,非常直观。我们还有其他方式来实现,“遍历一个容器中的每一个元素,查看有没有我们想要的”这一想法吗?

当然,我们可以用标准库里的 find_if() 函数,所以,我们最终把这段代码化解为 find_if() 函数。比起我们一开始的代码,这个解决方案更容易,也更简洁。为何8年前他们在第一次写这个代码的时候没有用最简单的方法(find_if())呢?他们是出色的程序员,即便如此,也没有发现化解的办法。

那是因为代码量太大,阻碍了视线。然而,经历了这一系列的化简步骤,结果就会变得很明显:当初他们应该直接采取最简洁的代码来实现(利用find_if())。

有意思的是,最优方法其实是C++98的解决方案。尽管通过C++11去发现这个问题也花费了一些过程,或许他们也会发现find_if()这一方法,但事实证明没有。这是一个真实的案例。

还有一些我非常不喜欢的地方。我希望在find_if()时只关注 v 容器本身,而不是从v.begin()看到v.end()。这个版本的代码可读性更好,直接表达了我想要的。

为了实现它,我们需要自己定义一个新的find_if() 函数来再一次简化代码。

这里还剩下一点可以在C++11里进行优化:如何表达容器Cont的iterator 呢?

答案是使用类型/模板别名,所以typename T::iterator可以用Iterator来表示。注意代码以后不需要到处写typename。通过类型函数的帮助,我可以得到如此简洁优雅的代码,我想不出更简单的了。

稍稍考虑了一会后,我回复了我朋友,问他:“要是5年前,我跟你说我能把你的产品代码量减半,你会是什么反应?”

我曾经过了一遍代码,当然咯,不是文件中所有代码都能化简,也不是所有的代码都能缩成一行,所以代码的总长度不会像示例中的这样变成原来的五分之一。在生产环境的代码中,我们或者他们将代码量减了一半。

要是五年前我告诉你这个你会怎么说?回复给的是:大力丸。就是说,这种一看就是销售人员的忽悠套路。不能信的。但不管怎么说,他自行做了重构。而且很明显,这很管用。如今这段代码正在生产环境下工作,部署之后的事情我就没听他提过了。照他的说法,这段代码和重构前一样地精巧、快速。简化并没有带来什么额外的损失。

我从中学到了一件事,就是渐进式的改进确实是很重要的。你不必一开始就洞悉细节。这办不到,大部分开发人员都办不到。只要能不断前进一点点,不断做出小的改进,最终这些会积少成多,将代码的规模减半,而且没有额外的性能开销。方向很重要,这样就有了进展,这就是进展。

我一直跟你们说,我们应该让简单的事情简单化。泛化当然很好,可以做任何事,处理任何情况。但有时候也会适得其反,你面对着模版文件、模版参数……或者是带一堆参数、处理繁冗细节的函数。我的意思是,你当然应该做到那些,但是你也应该能用简单的手法完成简单的任务。

那么,如何定义简单?简单意味着表达……代码直接表达出意图。看下这里的代码,很直接地描述了功能。

我们在做find_if操作,在容器 v 中查找匹配的模式,直接而精确地描述了我们在做什么。

之前的代码则很复杂,暴露了不必要的细节,增加了维护的复杂度。简单的代码理解起来就更容易,这就是简单化的含义。如果你了解标准库的algorithm,那你应该知道find_if()指的是什么,准确描述了你在做的事。我觉得这种写法很漂亮,而且有意思是,如果你将事物简单地、清晰地、明确地描述出来,那你就能理解它了。然后优化器、编译器都能理解它了。

另外,最简单的代码实际上常常是最快的。当然,不是所有的代码都能变得简单。有时候我们要做一些混乱的事,有时候我们面对的系统接口不是清晰定义的,有时候我们要和乱七八糟的硬件打交道,有时候我们要处理协议、隐藏的设计以及类似的东西,不要让这些接口的复杂度窜入你的程序中。试着用简单的接口隐藏它们,试着找出你真正想要做的事,让那件事成为你的接口,将复杂性隐藏在其后。

Ok~下面我打算聊点关于标准和标准化进程的东西。

也许你们有人还记得,1998年我们就有一个标准,它撑了很长一段时间。直到2011年我们有了一个新的标准。事情是这样的,我们本来一直打算在2007年推行新标准。当时大家觉得,像Fortran、C、C++以及Ada这些ISO标准化的语言,差不多十年会发布一个新版本。

这就造成,如果我们在2007年强推新标准,时间太赶,有人就不得不把一些东西推迟到2017年的标准中,这让人很失落。所以他们往里面加了大把大把大把他们的东西,这样到了2008年。他们觉着有些东西现在不加进去,就得捱到2018年了。于是他们就又向标准里加了更多的内容。这样我们就到了2009年。实际上,我们到了2011年才结束这个过程。

我们当中有些人,尤其是Herb Sutter(Herb Sutter在微软工作,也是标准化组织WG21的会议召集人),觉得这样算不上太好,我们不应该赶着点。所以我们决定使用火车模型。火车在2014年离开站台,要是你错过了,下一趟会在2017年发车。要是你又没赶上,2021年还有一趟。

我们讨论过应该隔多久发一趟车,最终决定是大约三年的样子。我强调这个,是因为我们发现一个现象,大伙儿总是尝试在发车前最后一分钟登车,导致列车延误。所以我们决定在2011年做一次大规模发布,2014年做一次小规模,然后2017年时又会有一次大规模发布。

有意思的是,我们准时发布了,两周前新标准通过了,我们有了C++14,也就是目前的新标准。现在正好是2014年,我们做到了,通过了要发布的标准。

编译器实现是什么情况呢?C++98从发布到有很好的编译器实现,花了差不多5年的时间。C++11时有了进步,去年我们有一些编译器实现了C++11,并且所有的编译器表现都很不错。今年我们有了两个编译器完整支持C++14,还有一个编译器也相当不错。也就是说,我们不仅仅准时发布标准。我们还随之准时发布了符合标准的编译器实现。你们要知道,之前没人做到过这点,这确实很了不起。

为了实现这点,我们采用了并行的方法。我们建立了很多研究组,这些组做文档和技术规范的工作。这样先放出一些ISO文档(如Nxxxx.pdf)。编译器作者依据这些文档实现语言特性。然后我们可以调整技术细节,融入我们在实际运用中发现的修改,最终整合进下一版标准。到达这里(2017年标准)确实有些交通拥堵。不过我们会想些办法的。

前面提过,C++14是一次小规模发布,其实算是完成了C++11。当你要发布一个大型项目时,总有些功能无法一起发布,因为总有特征蔓延。有些事情,只有产品开始使用后才会意识到。这就是C++14之于C++11的意义。它保含一些我们在C++11发布之后才会学到的东西。要是你们对下一次主发布的C++17有哪些内容感兴趣,这些是研究组及各自联系人的名字列,数目还不少。

要想多了解一些的话,你们可以前往C++官网:isocpp.org。在那里你点击“标准”,然后可以往下搜寻更多类似的信息。要是想追踪最新动态,你首先就该访问isocpp.org,因为上面有很多文章值得一读。要是官网满足不了你,那你可以去找这些文档和工作组。

只要你真正感兴趣,联系了这当中一些人后,你就可以加入进来,贡献自己的力量。来看下,这里有一系列的新特性。

特性列表真的很枯燥。我希望能给你们看更多的示例,可惜没有多少时间。所以我打算给你们看下这个列表,大致介绍下每一条。我会大致说下哪里能找到更多的信息,然后在问答环节,你们可以问我具体的问题。而不是花上3天时间解释每个条目。

C++11标准中一个很重要的事情,是为这门现代编程语言定义一个好的并发编程模型。如果之前看过C/C++标准,你会发现并发这种东西基本上不存在,全都是单线程计算,关于这一点,我们已经搞定了。我们很好地处理了并发性,而且不会降低任何程序的运行速度。

在C++11中,我们曾希望尽早了结相关问题,但是事情并不顺利。

我们最初的内存模型和并发模型是从Java借鉴来的,Java的并发模型不错,似乎也能用,而Java的这个模型确实也曾在我们考虑范围之内,但是不得不放弃。如果C++采纳了Java的内存模型,将导致Java的虚拟机的运行速度变慢(因为JVM是C++写的),所以在C++中不得不做一些更为复杂,更为高效的事情。

“切记切记不要使用Java的内存模型”, 这是Java专家这样告诉我们的。所以我们没有采用,这耽误了C++11的进度。最终我们有了一个确实很棒的内存模型,它一点也不影响性能,你可以放心。我们可以一如既往地使用线程和互斥器。这种方式并不是最好的并发编程手法,甚至可能是最差的一种,但是在系统级别上编程你必须知道这种写法。

我们还有了 atomics 和 auto,以及无锁编程。所以如果你觉得线程与互斥器的代价太大,你可以使用标准的方式来实现自己的同步原语,这个实现是可移植的,并且是类型安全的,这一点非常棒。

再也没有 void ** , 再也不用为Windows和Linux编写不同的版本。

我们已经能做得更好,这是一个重要的点。

接下来还有一些库,这里有计时支持,如果你还在用clock,那你就太落伍了。现在你可以更轻松而准确地测量时间。说到随机数,不要再用原来的rand(),我们有了更好的随机数,原来的rand()函数对你的程序不利。正则表达式,你现在可以在C++中使用正则表达式了。这里还有一些类型萃取,还有(模板)元编程支持,他们出现在这并不是因为我们想要鼓励元编程,他们在这是因为我们想简化元编程,使它不至于失控。

这里还有些好东西:unique_ptr, shared_ptr, make_shared(), make_unique()…可以让你更准确、简单、安全地管理资源。

哈希表终于被加入进来了!哈希表是我们在C++98时漏掉的一个特性,因为时间来不及了。我们花了半年多时间来确定哈希表的细节,结果就是,大家都构造了他们自己的哈希表。较广泛被使用的哈希表就有六种,我们一定要做出一个高质量的哈希表。因为市面上已经有六种哈希表,不能输给它们。他们之中的一些已经进入了std namespace,这是不应该发生的。所以我们做了unordered_map, unordered_set, 等等(多重集),以上就是哈希表。

我们还加入了元组。标准中还有其他一些较为普遍的提升:容器、算法。这边这个是move语义,我们可以移动一些东西,我们可以给函数按值传入一个vector,还可以让函数按值返回一个。受益于移动语义,这些操作很廉价。我可以从函数中按值返回一个包含上亿元素的vector,直接return它就行。代价大概是3次指针赋值,这也很棒。

C++14 TS中还有对文件系统的支持,使得我们可以控制文件、路径,还有目录什么的。我们还加了一个叫optional的类型,有些人非常喜欢这个,这等于是一个可选的值,你可以判断其值是否存在。

这里的语言特性确实很多,因为这个版本是一个主版本发布,不过基本上这使得C++看起来像是一个新语言了,你得学习一些新的东西,才能享受其益处。

如果你还是比较喜欢用原来的方式来写程序,没问题,但你一样会遇到你原来的bug,获得原来的性能表现,还有原来的维护上的问题。如果你用新的方式写代码,你能感觉到升级 , 当你写下这些东西的时候,它的感觉是完全不一样的。你们当中如果有尝试过的人,会明白我的意思。还没有试过的,请相信我。如果你们信不过我,去问问那些试过的人就知道了。

两者之间有些特别大的差异,我这里列出了move语义,auto还有初始化列表。现在有了初始化列表,所以你不必再现建立一个空的容器让后用其他东西填充,或者用默认值初始化完再改变其中的值。你只需要给出你的初始化列表就好了,可变参数模板,因此类模板可以有任意多个类型参数,函数可以有任意多个形参。

这里还有很多…那个是别名,我已经给出用法了。这里还有像是数字的分组分离,如果你想写一个超级长的数字字面量。你可以在这个变量中正确的地方插入单引号来将他们分隔开。如果你想说一千万的话,你不需要输入,还要担心自己到底有没有输入对正确的位数,你可以就写10’000’000 这样的形式。

我们说了上面一些小东西,还有再之前move语义和initializer这样真正大的东西。这里我就跳过一些东西,我们并不打算完全地把它们过一遍,我前面已经说过了。这些个东西都已经发布了, 你完全可以使用它们。

对于GCC, clang, MS(C++)这些编译器,我都或多或少在使用一些,并且我大部分的代码在这三个编译器上都运行良好。额~如果你还没有玩过C++14的话,去找个可以用的编译器试试看如何。

这些新特性中有很多都可以用来提高你的代码性能。我们所提供的语言的简洁性不以牺牲代码性能为代价,那不是我们想要的。C++应该成为最快的一种语言,并且它确实是这样的,并且在越来越快。比如说,你在C++11中会用到constexpr关键字,并且在C++14中会更多地用到。

你可以写出一个在编译时就能完成求值的表达式,这比运行时计算要来的快得多,因为它根本不需要在运行时做计算,你可以编译时就写出类型安全的函数和代码。move语意意味着着你不再需要指针打过多交道,这也有助于提升你的程序性能。

事实上,如果你使用C++14编译器重新编译C++98代码的话,往往发现速度变快了,因为move语义发挥了作用。即使你还没有对代码做任何改动,你已经在使用着最新的标准库。很多新东西都被设计出来,以简化我们编写的最常见的代码。比如前面一开始我给你们展示的那个小循环的例子。

是的,这些很琐碎,但你知道,它正变得甚至更琐碎这样才能更容易书写。以解放我们的脑力,用于那些真正值得我们花费脑力的东西上。简化维护很重要,所以我们在传统的复杂写法之外有了新的选择。

我们应尽量避免裸指针、裸的new和delete。我只要是在代码中看到一句delete,我基本能肯定代码在某处会有一个Bug。因为如果你需要delete,你很可能就会忘记了delete某样东西,你也可能两次释放了同一个对象,这就更糟糕了。如果delete没有隐藏在析构函数,或者专门设计来处理资源管理的函数里面,那么这段代码很可能有Bug。如果我读一段代码,我会看看有没有delete,如果有,那我很有信心改进这代码。

相似的,如果我看到一个new,那要么别处会有delete,这就回到了前面的情况,要么忘了delete。所以我并不想看到代码中出现,除非new出现在构造函数里,或着出现在资源handler的构造函数实参里。那才是它应该处的位置。如果new在其他地方出现,就往往属于裸new,那很可能会产生Bug。这也意味着,指针的出现同样值得怀疑,因为new和delete一定会和指针打交道。

这些内容我和很多人讲过并举过例子。而且每次都会有人说到这些语言特性会被误用。当然有人真的会误用。你见到过不会被误用的语义特性么?无论它是新的还是旧的。我的意思是我真的听说过各种说法。

早年,有人说C语言的for语句会被误用,因为它能做的事情太多了,也确实有人会误用它。虚函数也是常常被误用的。虚函数很有用么?是的。他们会被误用么?亦然。因此我们需要好好学习如何使用它。模板,当然可以被误用了。今天,很多C++程序取得高性能的关键之处就在于使用了模板。这个一个螺丝刀,非常古老的工具,它可以被错误地使用么?嗯。(点头表示同意)除了打开铁罐头之外,它还被拿来做了什么呢?所以,对这种批评不要放在心上。

值得花心思的是学会什么才是合适的用法,至少要考虑好什么是对这些新特性的负责任的用法。不要恐慌,也不要只是为了使用新特性而做过头的事情。你要搞懂哪些是应该避免的,哪些可以实际使用。所以,请认小心地学习。所有的特性曾经都是新的。他们是新特性,但不久之后就会成为旧的,我们会发明出更好的东西出来。

这是我从Herb Sutter的演讲中摘录的一个例子。这是一种我们大部分人在C++ 98标准及以前写的代码。它做了什么呢?先创建了一个circle对象,再从文件加载了一堆shape(形状),放入元素为shape指针的vector容器,然后做了一些事情。

在这个例子中,我就做了这件事:用一个循环去检查是否有shape和这个circle匹配,真的很简单。这只是个基本的代码例子,你肯定也见过,这段代码可以正常工作。代码还行,在1990年代算得上是好代码。在某个时候我们还必须记得做一些清理工作。因为这里我们从文件中加载了一些shape对象,所以我们必须去delete这些对象。好的,尽管这曾经是好代码,但现在不是了。

而今天我们看到的代码是这个样子的,创建一个circle,保存在unique_ptr中,具有对象的所有权。这意味着一旦unique_ptr离开作用域,对象就被delete。谓之“智能指针”也。将会在析构的时候delete其指向的对象。

我们加载了这些shape对象,保存到auto变量中,(指上一行)这里我说了要一个unique_ptr,所以类型就不必重复写出。load_shapes()这一行也不必重复写出类型,因为编译器已经知道其类型了。

接下来我对其中的元素做了一个循环,这里我用了range-for循环,否则代码和前面一样。好处就体现出来了, 这一段代码中,我不需要再用指针了。因为circle归unique_ptr管,而load_shape()会返回vector或vector。因此,资源管理的问题就不存在了。这就是全部的代码,没有出现delete。此外,旧的代码不是异常安全的,而新的代码是对异常安全的,尽管我都没有明确处理异常。这好多了。

以上就是我演讲的所有内容,下面是问答环节。建忠,交给你了。(问答环节省略)

2016 C++及系统软件技术大会

将于2016年10月28日-29日,在上海盛大举行。圈内元祖级大咖都来了——

C++之父 / Bjarne Stroustrup
前Facebook研究科学家 / Andrei Alexandrescu
ISO C++标准委员会资深权威 / Mike Spertus
《大话西游》《梦幻西游》主要开发者 / 云风
两岸著名C++专家 / 侯捷
……(共40多位重量级嘉宾)

C++谜弟表示要原地炸裂了!

“阅读原文”即可报名参加

【撒福利啦】扫上方二维码关注大会公众号,并回复“C++大会PPT”,即可免费领取大会完整PPT资料!还可进群参加C++系列大咖直播~

转载自演道,想查看更及时的互联网产品技术热点文章请点击http://go2live.cn

发表评论

电子邮件地址不会被公开。 必填项已用*标注