http://jackxiang.com/index.php zh-cn http://jackxiang.com/post// jack <xdy108@126.com> Fri, 16 Oct 2009 17:07:50 +0000 http://jackxiang.com/post// C++ - Myths and Fallacies (rev#1)

或“争论C++前你应当知道什么”



最近写了一篇关于C++0x Concepts的文章，意料之外地引起了一场小规模口水仗。回各位帖子的同时，回想这些年C++社群的大小争论，觉得有必要把一些长久以来在C++争论中出现的误解列举出来。



注：这篇文章行文匆忙，但观点不匆忙。匆忙的问题在于可能还没有列举出所有的fallacies。所以我在文章标题上加了个rev#1。如果你看了之后觉得有什么fallacy要补充的，欢迎在回帖内指出。我会考虑加入下一个review版本:-)





… History became legend, legend became myth …

- The Lord of the Rings



哈雷将军的笑话想必大家都听过。一句话经口口相传，每个人都根据自己的主观意念加以润色，修补，歪曲… 到最后就面目全非。这里最关键的一环就是主观意识，在历史学里面有这么一句话，大致意思是历史其实只存在于人的意念之中；就算完全客观的事件，通过不同的人的嘴说出来，造成的心理效应也往往不一样，每个人都会加上那么一两个形容词，驾驭语言能力高的更是能够舌绽莲花，而语言本就有自身的力量，其中的遣词造句对读者构成的心理影响力便应运而生。甚至于同一句话，用不同的语气说出来，都会造成不同的效果。同一句话，站在不同的立场上看，也会根本不是同一个意思。比如“C++还算是门不错的语言”，站在C++拥护者的角度听是在怜悯加诋毁C++，而站在C++反对者的角度听却是抬举了C++。



在一个长期被广泛争论的话题中，几乎无可避免的总是存在一些Fallacies和Myths。比如动态&静态类型系统的争论，据说从图灵时代就开始了，到现在还有各种各样的误解，而且，可以说，时间越长，系统内的Fallacy越多。就连异常（exception）这样不算复杂的语言特性里面居然也有一些长期存在的误解。



至于这些Fallacies和Myths出现的原因很多：有人要“内涵”唬人、有人要维护自己的心理优势、有人要维护自己的政权、有人要维护自己的利益、有人因为话从别人那里听了半句转述给别人听的时候按主观意念补全（谁愿意说“我不知道”呢？）、有人干脆就是人云亦云…



所以，一句话，在一个靠口头表达交换信息的社会中，Fallacies和Myths是无处不在的，因为从内心真实想法到外界表现出来的想法之间存在着“口头表达”这一中间层，后者由主观意志支配。这里的中间层可不比软件工程里面的间接层，在这个间接层上恶魔可以变成天使，天使也可以变成恶魔；六月飞雪可以变成天降祥瑞，瓢泼大雨也可以变成艳阳高照。Anyway，这展开来就是一个心理学的问题了，不多废话了，有兴趣的可以去看Harry G. Frankfurt写的《On Bullshit》或者Scott Berkun的这篇短文——“How to detect bullshit”。呃…我说“一句话”了么？



C++ - Fallacies and Myths

C++作为一门被争论不断的语言，其中Fallacies和Myths自然不会少。一般来说，一个问题在被大众争论中交换的话语数量与其中的Fallacy数量成正比。但一般来说主要的Fallacies就那么几个：



Fallacy #1 —— C++社群的哲学太学院派

让我们先对“学院派”下一个定义好不好？先问你自己一个问题，你心目中对“学院派”的定义是什么？



以下是一些选项：



1. 倾向于理论美。

2. 忽视实际编码中的constraints（如效率，模块性、可读性等等）。

3. 倡导语言律师行为。

4. 钻细节。

5. …



我想如果我说C++语言设计强调理论美，所有学过C++的人恐怕都会笑了… 正如Bjarne自己所说的，C++设计初期的Rule of Thumb之一便是“不要陷入到对完美性的固执追求中”；不过具有讽刺意味的是，后面你会看到，正是这样的一种哲学带来了今天对C++的这个误解。



我猜持这样一种观点的人大多对于学院派的定义都是模糊的，一般都介于“提倡钻语言细节并利用语言细节的做法”、“关注语言特性本身而忽略实际编码需求”、“对语言细节无休止的争论”等等之间。



所以，当有人说“C++==学院派”的时候，他的真实意思很可能是：“C++语言的阴暗角落太多，而且C++社群还有提倡对语言角落把握的潜在哲学，就连C++0x的进化也似乎更多关注语言特性，而那些语言特性根本就跟我们实际开发者脱节了…”等等。



首先得承认的是，在近一个十年的时间内，C++社群的确某种程度上建立起了一种对语言细节过分关注的心态，这种心态毫无疑问是错误的，但只有知道这个错误是如何来的，才能解开这个结。而且，就算一时解不开这个结，知道了原因之后才能保持理性的宽容态度，而不是乱发抱怨。一个理性的态度，更有助于良性发展。例如如果C++社群都能明白这种潜哲学从何而来，或许也就会渐渐走向更好的发展了。



我用一个例子来说明这一点：你平时遍历一个数组，或一个容器的时候是怎么做的？



for(std::vector::iterator it = v.begin(); it != v.end(); ++it) {

…

}



这种做法很臃肿。其实你的逻辑是“对v中的每个元素，做…事情”，你知道大多数其它流行的语言中都有内建的for_each。那C++中就没有了吗？有。STL的for_each算法，于是你写：



struct MyOp

{

void operator()(int& i)

{

…

}

};



std::for_each(v.begin(), v.end(), MyOp());



这个方案实际很差。一是你还是得写v.begin()、v.end()，二是你得为此定义一整个新类。三是这个新类并不在你使用这个新类（for_each被调用）的点上，因为局部类不能做模板参数。



你要的是lambda function：



for_each(v.begin(), v.end(), <>(int& i){ … });



可是C++98没有。



你要的是内建foreach：



for(int& i : v) {

…

}



可是C++98没有。



鉴于循环结构是编程中最常出现的结构之一。这个问题其实还是比较恼人的，如果你觉得不恼人可能只是因为你适应性习惯了，这未必是好事。比如每次都要写std::vector::iterator就很让人恼火，如果我换个容器，就要修改一堆std::vector<…>。那用typedef行不行啊？行。可仍然还是需要写一次typedef，我很懒，我什么多余的无用代码都不想写。要知道，每多出一行无用的（并非因表达思想所需要才出现）的代码，就增加一点维护负担，这也正是为什么语言的表达力如此重要的原因。



那怎么办？如果我告诉你，C++98里面其实你也可以写：



foreach(int& i , v){

  …

}



你怎么想？



废话。当然是求之不得了。有这么简洁的表达方式谁还不想用啊。



我需要告诉你的另一个事实是。为了在C++98里面几近完美地实现这个特性，有人把标准的角落挖了个底朝天。不，我不是在为钻语言细节找理由，我只是想告诉你，许多人所认为的钻语言细节的做法，其实一开始大多是由用户实际需求驱动的，这个foreach设施被C++程序员们试图实现了N遍N种做法，可见需求之强烈。可惜绝大多数实现都远远称不上好用，就连现在这个实现的作者也早在03年在CUJ上发了一个实现，也称不上好用。是后来又契而不舍才实现了最终这个真正好用的版本的。



我想说的是，上面这个美好的foreach，当然人人都想用。但问题是要在C++98下实现它只能靠挖标准，这是唯一的途径。要不然就得等语言进化，并忍受若干年，谁愿意？况且这个foreach设施还能作占位符，在C++09来临之前兢兢业业履行其职责，C++09加入内建foreach支持之后只消用正则表达式搜索全局替换，就OK了，没有任何的升级麻烦。



再举一个经典的例子：STL里面的traits。其实traits不应该是traits。traits最自然的实现方式应该是C++09的concept。但STL需要用到静态dispatch技术啊，那怎么办？要么用traits（增加语言复杂性），要么不用（显然不行）。



再举个经典的例子：模板元编程。模板元编程有啥用？日常开发者八辈子估计也用不到。但真的吗？没错，日常开发者并不会直接用到。但是，由模板元编程支持的各个boost子库呢？被选入C++0x的TR1的各个子库呢（间接用到）？那日常开发者用不用学模板元编程呢？不用学，根本不用学，这么复杂的技术学什么呢？也就是点技巧上的东西。那为什么偏有人学呢？待会再说。



还有大量的例子就不一一列了。其实STL的traits技术已经能够说明问题了。如果你仔细看一看，你会发现，那些所谓的利用C++黑暗角落的技术，几乎无一不是出现在库开发里面的，而之所以出现在库开发里面，是因为库开发中的需求驱动的——为了开发出更好的库。难道你不想用更好的库？



哦，说到“更好的库”，肯定会有同学有意见了。C++98都快十年了，标准库还是只有那一套STL。库进展缓慢，到现在GUI库也没有一个标准，都是四分五裂各自为营。网络库也是、文件系统库也是、日志库也是… 不过这个问题已经是另一个问题了，容后再说。



问题是，“没有标准的库”并不意味着“C++的库不好”，后者也并不意味着“那些晦涩的技巧并没有提升库的质量”，这个逻辑上的两环都不对。实际上，人们所谓的“晦涩而复杂的技巧”其实正是为了提升库的质量而被挖掘出来的。traits技术提升库的效率（静态转发），type erase技术使得boost::function可以接受任何签名为void()的函数（灵活性），包括仿函数，包括boost::bind后的函数。type list技术使得boost::tuple能够接受可变数目的模板参数。policy-based design使得可以对一个设施的功能进行正交分解…



就算把所有流行的C++ tricks都列出来，你也会发现，其实它们几乎每一个都对应了至少一个实际应用。而实际应用需求哪来的？库设计的需求。但归根到底，是使用库的人——终端程序员——的需求。（效率、灵活性、抽象表达力，哪一样不是终端程序员的实际需求呢？）



再举个实例，有同学说，我只要写简单的代码。问题是，简单不意味着单纯。简单意味着在更高抽象层次上面编程，后者是要靠好的库抽象才能达到的。借用《Extended STL》里面的一个例子：



DIR*  dir = opendir(".");

if(NULL != dir)

{

  struct dirent*  de;

  for(; NULL != (de = readdir(dir)); )

  {

    struct stat st;

    if( 0 == stat(de->d_name, &st) &&

        S_IFREG == (st.st_mode & S_IFMT))

    {

      remove(de->d_name);

    }

  }

  closedir(dir);

}



这段代码删除当前目录中所有文件。



readdir_sequence entries(".", readdir_sequence::files);



std::for_each(entries.begin(), entries.end(), ::remove);



这段代码做同样的事情——哪个更简单？



那问题是，为什么发展到后来，“钻语言细节”成了社群的潜在哲学呢？



这其实是一个心理学上的问题，跟语言没有关系，跟C++的初衷更没有关系。从心理上，在同一个领域，如果另一个人比你懂得更多，你就会倾向于佩服他，这时另一个人懂的东西有多大的用处其实并不那么重要，人对自己不懂的东西总是有一种敬畏感的。C++里面有那么多的tricks，其实日常编程中要用到的trick少之又少，日常编程绝大多数都以复用库为主，而那些tricks就隐藏在库里面。除非你是库的设计者，否则很多的tricks根本就无需关注。另一方面，写作C++书籍的大多数都是C++库的设计者，这就给予了许多C++书一个有偏见的视角，大量库设计中才会用到的技术被介绍出来，而社群对这些牛人又都是唯马首是瞻的。（其实我觉得一本Bjarne的《The C++ Programming Language》加上一本Herb&Alexandrescu的《C++ Coding Standard》对于日常程序员来说，真的足够了。）



此外，人总是好奇的，在C++里面有那么多的被“发明”的好玩技术，怎么可能不会有人去追捧呢。另一个动机则是学了这些技术有立竿见影的炫耀效果，比如在论坛上。这可比编写可维护代码的才能容易表现多了——人自然是更倾向于去关注那些更容易拿来表现和炫耀的东西的。退一步说，就单单是“发明”一项新的语言特性组合运用技巧都能带来纯粹的成就感，因为你又在现有语言框架下作出了一个创举，你做了别人做不到的。而作为学习者，你可能会因为发现原来自己理解的一块土地上还有不知道的东西而感到兴奋和新奇，这种兴奋和新奇感往往是学习的真正原动力。至少，对于我来说，当年读《Modern C++ Design》时正是这样一种感觉，我想有和我一样感觉的人肯定不在少数。



再来，一个是在人前看不见摸不着的编码能力，另一个是对handy的技巧的掌握。作为一个学习者，倾向于学习后者，因为后者学起来更容易，而且也往往更有趣。学到了之后能够得到跟解决重大问题同等的成就感——看看《Effective C++》系列受到的追捧就知道了。



再来，当你面临两个问题，一个是如何建立一个高质量的库（大），一个是如何修正库里面的小bug（如vector里面某个成员函数的异常保证问题）。如果你有一份时间，你更倾向于把它花在什么地方？人在心理上总是倾向于走“捷径”的，体现在这个问题上面便是更倾向于对付耍点小聪明就解决的小问题，并获得甚至并不亚于解决大问题的成就感。小问题的另一个吸引人的地方在于它耗时短，更“趁手”，它不需要你闭关苦苦编码几个月弄出一个框架来而且还不一定能成。所以这就给人一种错觉，C++社群只知道争论枝节问题，不知道实干库。哦，不是错觉，这的确是大部分的现状，但这个现象其实并不仅仅止于C++社群，这是人心理的共性造成的，这也就是为什么无论在哪个语言社群你都会看到争论最多的都是些“小问题”的原因。（当然，无论在哪个学科，也还总是有牛人去啃难啃的骨头的。但这并不是广大民众的状况。）



以上种种原因共同造就了C++社群的这种心态。这其实跟C++的“教义”没有关系。C++如果有教义的话也是实用为上。这种现状是自发产生的，它的动力来源于人的心理。如果Java语言有各种各样的特性组合，且这些特性组合能够某些时候满足开发中的实际需求的话，也是一样会出现这样的情况的（事实上一个小小的Java Closure就已经引起了大量口水了）。某种程度上，LISP里面用函数来实现自然数系统，也是一样的道理，你敢说，你第一次看到它的时候，不惊叹？人之常情而已。



那这种哲学对不对？废话。当然不对。不但不对，而且有害。很多C++日常开发者在学习库开发技巧上浪费了很多时间，掌握了根本用不到的技术，而且这些技术，不如称为技巧，可能还会随着语言进化变得根本无用武之地。还不如好好学学如何让自己的代码更KISS呢，基本的编码准则要远远重要得多，正如我刚才说的，日常开发，一本《The C++ Programming Languag》加一本《C++ Coding Standard》足够了。



另外，说到语言进化顺便说一句，语言进化的职责之一便是废黜繁复的技巧，取代以直接表达思想的语言特性。而C++0x真正在履行这一职责。



最后来说一说前面留下来的一个问题：为什么C++设计的初衷——“不要固执于完美”——某种程度上带来了这个局面呢？



因为正是因为这种理念的指导，有不少语言特性从理论上都是不完备的：比如有copy语意没有move语意（有左值引用没有右值引用），于是Alexandrescu用Mojo框架来解决；比如支持可变参数的函数调用却不支持可变参数的模板参数列表，导致用元编程来解决；比如不支持构造函数转发，导致必须factor出一个公共的initialize函数来；比如不支持强类型的enum，结果用一大堆宏结合类来解决；比如不支持initializer list，结果用复杂的模板技术来实现某种类似的初始化方式；比如不支持auto和typeof，结果用更复杂N倍的模板元编程技术来实现一个模拟；比如不支持内建的alignment指示，导致Alexandrescu在实现类型安全的union的时候用尽了模板元编程技巧；比如不支持内建的foreach，结果借助于诡异的语言角落实现了一个几近完美的模拟；比如不支持内建的concept，导致使用模板技巧来实现也算能用的concept检查… 这个列表可以一再延长下去，C++中这样的示例太多了。C++的不完美导致了各种各样的技巧应运而生，哦，不，应该说，应实际需求而生。这从另一个侧面正说明了一点——



C++太需要进化了！



Fallacy #2 —— C++委员会过分关注一些不切实际的语言特性，而不关心标准库的扩充

比起第一个fallacy来，这个倒容易解释清楚了。人家Bjarne在文章和访谈里面一再强调，C++从来都是把库设计放在首位的（这句话其实就意味着，是把最终开发者放在首位的——什么？你难道不用库？），但是C++群体是一个分散多样的群体，而且没有大公司的财力支持。前者意味着众口难调（标准化过程困难），后者意味着不能集中精英的人力（boost库的开发都是由大家业余时间完成的）来搞出个百万美元的免费库来。此外个人用业余时间来开发库还意味着往往没有足够的精力来对库进行精化改善，导致库的质量不佳或者干脆停滞（这样的C++库案例很多）。比如日志库吧，没有一打也有半打，但由于都是个人业余开发，所以没有精力做到尽善尽美，唯一一个往boost提交的是John Torjo（也是个牛人）写的，不过一年前被reject之后就没了动静。你难道怪人家？人家又不是你雇来的。



但说到底，还是钱的问题，众口难调还是终究能调的（boost发起的初衷便在于此）。但没有钱，鬼才跟你推磨呢。



不过好消息是据说boost明年能拿到fund:-) 应该能把boost狠狠boost一把。



至于“C++委员会过分关注一些不切实际的语言特性”就不知从何说起了。首先，前文已经明确说明语言进化的重要性以及实用性，这说明语言进化根本不像人们认为的那样“不切实际”，而是与实用休戚相关的。其实从根本上，语言进化就是为了带来更好的库，以及更好的代码（包括日常编码），这一点跟大伙殷殷企盼着标准库其实并不相左。此外还有一点就是，讨论语言特性比实际去开发库要花更少的精力，这两者花的精力其实不在一个数量级上，开发一个库出来要难得多得多，所以就造成了一种假象——“委员会的那帮家伙只知道倒腾语言”。这个论点错在了两个地方，一，倒腾语言是必要的。二，他们并非只知道倒腾语言，只是库的问题要艰难得多，没钱，人家难道砸锅卖铁给你开发标准库吗？



有同学说，我只要一个能用的库就行了。但问题是，标准库能随便吗？标准库之所以不能随便，是因为像这样受众极其广泛的库可是要负责任的——将会有百万千万行代码都依赖它。如果标准库里面有bug，将会出现几百万上千万行workarounds，这些workarounds依赖于库的bug，为了保持向后兼容性，标准库甚至都不能修正这些bug。就连STL这样漂亮的抽象，迭代器区间还是闯了祸。另一方面，如果只是需要一个能用的库，C++社区有大量“能用”的库。姑且不说boost里面的了。



Fallacy #3 —— C++的强处在于什么都能做

一个最常见的论调就是，java的虚拟机也是C++做的，于是得出结论，java比C++弱，java没有C++好。



姑且不说“好”的定义标准是什么。就算java的虚拟机做的，那C++的第一个编译器还要用C写呢。C库里面的某些成分还要用汇编写呢。这个论据是站不住脚的。



其实，持这种论点的人是站错了位置，问错了问题。



关键的问题不是一门语言能做什么，因为说到能做什么，汇编什么都能做。而是“在某个特定的领域，哪门语言表现更好”，人们的需求几乎总是对着某个特定的领域的。后者才是真正matter的问题。



从这个角度看，C++的市场其实只在效率这一块。有人可能会说，那效率这一块有C啊。问题是，C的抽象机制太弱。写架构简单的应用，或者写一些核心的（如驱动程序），没有面向对象结构的程序，容易。完全可以用C。但涉及到大型系统，比如.NET基层架构，一些3D游戏。必须用到面向对象或基于对象编程的领域，C在代码组织和抽象方面的弱点就暴露出来了。比如用C和宏来实现所谓OO，就正说明了C的抽象机制的薄弱。



但是，C++的领土基本也就在这些地方了。简而言之就是所有“效率重要，且同时需要好的抽象机制的应用领域”。因为C++的优势就是无损效率的实现更好的抽象。



那C++既有效率又有更好的抽象机制，为什么C++不能取代java、不能取代python，不能取代ruby？或者至少当C++进化到更好的阶段的时候，比如C++0x就是一个大的进展（在语言方面），为什么作为一门语言，不能取代那些严重“偏科”的语言呢？



原因有两方面。一方面，正因为“偏科”，所以有些语言才能在它们擅长的领域做得更好，乃至做到最好。“偏执狂才能生存”。人们的需求几乎总是在特定领域的，你说这时候人是愿意选用一门专门为这个领域而生的语言（ruby），还是愿意用一门general-purpose的语言（C++）？另一方面，就算C++在抽象机制上进化到了非常好，乃至于能在某些特定领域也表现不菲的话，由于市场早就被别的语言侵占，别的语言已经有了成百上千万行的代码基，别的语言的库已经发展到非常丰富的程度，别的语言的相关人才教育已经一代又一代，所以结果还是没得拼。



其实，从另一个角度来说，C++何尝不也是一门偏执的语言呢？C++的偏执就是效率，C的偏执也是效率，但C++提供更好的抽象，因此在这一块（效率+抽象），C++比C有优势。



C++的领土已经铸成，另一方面，C++的领土在可见的未来也不大可能缩水了。这是C++的现实，这个现实，至少在Bjarne看来，也没什么不好，因为它正反映了C++当时设计的意图——更好的C。我们也不用赶鸭子上架，非拿C++和其它语言比——适用的场合本就不同，没得比。



Fallacy #4 …

事不过三，就此打住。况且，这三条难道还不够吗？如果你想到还有什么fallacy要补充的，请不吝回帖:) 我会考虑加到文章里面的:)

学习C++：实践者的方法：





前言

我的blog以前很长一段时间关注的都是C++中的技术&细节，乃至于读者和应者都寥寥。然而5月份的时候写的一篇“你应当如何学习C++”，阅读量却达到了3万多，在blog上所有文章中却是最高的（且远远超过了第二位）；评论数目也有一百多。为什么独独这篇能够激起这么多的回应，想必是国内的C++社群被C++压抑太久，或者，严格来说，是被C++的教育方式压抑太久。实际上，不管是在各大国内论坛上，还是在comp.lang.c++.moderated这样的国际C++论坛上，乃至于在douban上的小组内，有心者都会发现，对C++语言的细节的关注一直都没有停止过，同样，对C++语言的细节的抱怨也从来都没有停止过。一个例子就是comp.lang.c++.moderated上的一个技术牛人James Kanze说的，他说接触C++十年了，到现在还需要不时去翻C++标准。这就难怪Eric Raymond老大在《The Art of Unix Programming》中说“C++是反紧凑”的了。C++中的细节太多，就算都看过了，也不可能都记住。更关键的是，就算都记住了，也不能让你成为一个真正的好程序员。

绝大多数人都把细节太多（或者用贬义词来说就是“阴暗角落太多”）归结为C++的本质问题，认为一切邪恶由此而生。也正因此，大约9月份的时候，Linus在邮件列表上说“C++是一门有思想包袱的语言；仅仅是为了让程序员远离C++，我也要用C”。这句短短的话在国内引起了很大的反应，最初是刘江转了Linus的话，然后云风和孟岩都发表了自己的看法；我也写了一篇“Why C++”（后来发给Bjarne，Bjarne对这篇文章做了一个友情评注）。

然而，这一通浑水搅过之后，我相信引起的变化未必很大。大多数原先的反对者能从中找出反对的理由，于是更加反对；大多数原先的赞同者也能从中找到赞同的理由，于是更加赞同；而剩下来的原先没有明确意见的，看双方各有各的道理，可能还是没有头绪。

摆脱自我服务偏见——理性思考的前提

《决策与判断》上提到过一个有趣的真实故事：1980年的某一天，美国空战司令部的计算机突然发出警报——苏联的一枚核弹正在向美国本土飞来。司令部立即调兵遣将，迅速为一场核战做好了准备，然而3分钟之后，工程人员发现是计算机的一个小零部件故障造成的。然而，这场虚惊之后，大众的反应才是真正有意思的：原先支持核武装的，认为现在感觉更加安全了（因为“事实证明这类的故障是完全可克服的”）；而原先反对核武装的则认为更不安全了（因为“这类错误信号可能导致苏联过度反应，引发真正的核战”）。类似的情况也发生在三里岛核泄露事件之后，同样的，反对者认为（“这表明管理部门没有办法安全管理核能”），支持者认为（“这正表明这样的危险没有想像得那么严重，是可克服的”）。社会心理学把诸如此类的现象总结为“自我服务偏见”。不幸的是，“真理越辩越明”其实只适用于理性思考者。

为什么啰嗦这么一大通呢？就是因为，一直以来泛滥于程序员社群的“语言之争”，背后真正的原因其实并不在于语言实质上的优劣，而在于观察者的眼睛。在观察者的眼睛里面，语言并非一门工具，而是自己花了N多时间（其中尤数C++为最）来“修炼”的技能，对于这样的技能，被否定无疑等同于自己被否定。所以，从心理学上讲，语言并不是工具（尽管一直有这么一种呼吁），而是信仰。这样的信仰在越是花得时间久的语言上越是激烈。有趣的是，几乎所有的“热闹”的社群都有这样的现象，Java、Python、Ruby…莫不如是；因为就算语言本身不复杂，程序员仍然还是要投入大量的精力去学习各种各样的框架类库（想想Java的那些框架？）。因此这些语言社区的信仰未必不比C++社群的强烈。

然而，一旦弄清我们为什么会把语言当成信仰，就非常有助于摆脱在看待语言时的“自我服务偏见”，从客观的角度去看待问题。——“当你看到的是支持某个意见的证据时，试着去想一想有哪些证据是不支持它的”。

那么为什么要摆脱自我服务偏见？说小了，是为了成为一个更优秀的程序员（谁也不希望因为偏见而去使用一门低效的语言乃至不妥当的语言）。说大了是节省生命（因为偏见可能导致越陷越深，浪费时间）。

所以，如果你能够理性的思考我们将要讨论的问题，避免自我服务偏见（就当你从来没有花时间在C++上一样）。那么我们便可以开始讨论真正的问题了。

前言2

现在，几乎每个学习C++的都知道C++的核心问题是其复杂性；甚至本身不在C++社群的，也知道这是事实。群众的眼睛是雪亮的，何况这还是个太显而易见的事实。

但看了无数篇阐述C++复杂性的文章，和争论C++复杂性的吐沫星子（包括我前段时间写的两篇关于C++的总结）。我始终都有一个感觉——没分析透，就跟盲人摸象一样。正如“Why C++”的一位读者批评的，我在文章里面没有写明到底哪些是C++的“非本质复杂性”。当然，我自己凭感觉就能知道，而接触C++一段时间的人大致也能知道，但新手乃至非新手则对我所谓的“非本质复杂性”根本没有一个具体的认识，这就使得那篇“Why C++”脱离了原本的意图——面向所有C++使用者和学习者。

同样的原因，在写了“你应当如何学习C++”一文之后，当孟岩先生邀请我给《程序员》写一个系列的文章，介绍一下我在接触C++的过程中的态度和认识转变时，我虽然非常高兴的答应了，但直到现在3个月过去了还是颗粒无收。为什么？因为我觉得真正本质的问题没有被清晰的触摸到；所以直到现在我都没有动笔，免得废话说了一大堆，除了能被当成小说读读之外，对真正考虑是否要学习乃至使用C++的人未必有什么实际用处。

然而，这么个念头一直都放在潜意识里面。前一阵子和Bjarne通信，谈到了关于C++复杂性的一些想法，在邮件里面总结了一下C++的复杂性来源，感觉思路清晰了许多。而这篇文章要达到的目的，正是传达对C++的复杂性的一个具体而明确的认识，有了这个认识作为支持，我们便可以推导出学习C++的最佳（实践者）的方法。

为什么要学习（并使用）C++

显然，如果找不出要学习C++的理由，那么谈什么“正确的学习方法”等于是废话。

首先重复一句Bjarne的话：“我们的系统已经是极度复杂的了，为了避开C++的复杂性而干脆不用C++（Linus的做法），无异于因噎废食。”在所有可用C和C++的领域，C++都是比C更好的语言。当我说“更好的”时候，我说的是C++拥有比C更安全的类型检查、更好的抽象机制、更优秀的库。当然，凡事都有例外，如果你做的项目1）不大。2）编码中用不到什么抽象机制，甚至ADT（抽象数据类型，例如std::complex这种不含多态和继承的）也用不到，RAII也用不到，异常也用不到。3）你连基础库（如，简化资源管理的智能指针、智能容器）都用不着。那么也许你用C的确没问题；所以如果你的情况如此，不用和我争论，因为我无法反驳你。我们这里说的领域大致是Bjarne在“C++应用列表”里面列出来的那些地方。

底线是：如果把C++中的诸多不必要的复杂性去掉，留下那些本质的，重要的语言特性，简化语言模型，消除历史包袱。即便是C++的反对者也许也很难找到理由说“我还是不用C++”。在我看来，一个真正从实践意义上理性反对使用C++的人只有一个理由：C++的复杂性带来的混乱抵消乃至超过了C++的抽象机制和库（在他的特定项目中）带来的好处。

值得注意的是，这里需要避免一个陷阱，就是一旦人们认定了“C++不好”，那么这个理由就会“长出自己的脚来”，即，就算我们拿掉C++的复杂性，他们可能也会坚持还是不用C++，并为之找一堆理由。我假定你不是这样的人。不过，也许最可能的是他会说：“问题是我们今天用的C++并非如此（简洁），你的假设不成立。”是的，我的假设不成立。但虽然我们无法消除复杂性，我们实际上是可以容易地避开复杂性，避短扬长的。这也是本文的要点，容我后面再详述。

当然，到现在你可能还是会说。我还是不用C++，因为我可以用D；或者如果你本来做的项目就不需要C++，你则可能会说，我用Python。首先，如果你的项目能用Java/Python乃至Ruby做，那么用C++是自讨苦吃。因为能用那些语言代表你的项目在效率上本身要求就不高，那么用一门效率上讨不到太大好处，复杂性上却绰绰有余的语言，有什么价值呢？其次，如果你的项目效率是很重要的，你可能会说可以用D。然而现实是D在工业界尤其是国内被运用得非常少，几乎没有。而C++却有大量的既有代码，已经使用C++去做他们的产品的公司，在很长一段时间之内几乎是不可能用别的语言重写代码的，正如Joel所说，决定重写一个非平凡的代码基==自杀。所以，我们至少要注意以下两个明显的事实：

事实1：C++在工业界仍有稳定的核心市场。

这个事实大概不需要多加阐述，很多大公司的核心技术还是要靠C++来支撑的（见Bjarne主页上的C++应用列表）。所谓事实，就是未必是大家最愿意承认的情况，但又不得不承认。C++积累了庞大的代码基，这个代码基不是一朝一夕能够推翻的。D从语言角度来说的确优于C++，但最关键的就是还没有深入工业界（也许根本原因是没有钱支持，但这不是我们讨论的重点）。而C呢，根据Bjarne本人的说法，他的观察是主流工业界的趋势一直是“从C到C++”的，而不是反过来，至少在欧美是如此。在国内我们则可以通过CSDN上的招聘情况得到一个大致类似的信息。

事实2：C++程序员往往能享受到有竞争力的薪酬。

是的，这不是一篇不食人间烟火的技术文章。这个事实基于的逻辑很简单：物以稀为贵。Andrei Alexandrescu这次来中国SD2.0大会的时候，在接受采访时也说过：“最赚钱的软件（如MS Office）是C++写的”。孟岩也在blog上提到这么个事实，我想他作为CSDN的技术总编，业界观察肯定比我清晰深刻。所以我这里就不多废话了。

当然，以上逻辑并不就意味着在怂恿你去学C++，一切还要看你的兴趣。所以如果你志不在C++身处的那些应用领域，那这篇文章并非为你而写。

“C++的复杂性是根本原因”——一个有漏洞的推理

一旦我们认识了C++在一些领域是有需求的（值得学习和掌握的）这个问题之后，就可以接下来讨论“怎样正确学习和掌握C++”这个核心问题了。

其实，对于这个问题，Bjarne已经宣传了十年。早在99年的时候Bjarne就写了“Learning C++ as A New Language”，并在好几篇技术访谈（这里，这里，这里，还有这里）里面提到如何正确对待和使用C++中支持的多种抽象机制的问题。Andrew Koenig也写了一本现代C++教程《Accelerated C++》（这本书后面还会提到）。然而这么多年来，C++社群的状况改善了吗？就我所知，就算有改善，也是很小的。学习者还是盲目钻语言细节，只见树木不见森林；网上还是弥漫着各种各样的“技术”文章和不靠谱的“学习C++的XX个建议”；一些业界的有身份的专家还是在一本接一本的出语言孔乙己的书（写一些普通程序员八辈子用不着的技巧和碰不着的角落）；而业界真正使用C++的公司在面试的时候还总是问一些边边角角的细节问题，而不是考察编程的基本素养（不，掌握所有的语言细节也不能让你成为一个合格的程序员）。这个面试理念是错误的，估计其背后的推理应该是“如果这个家伙不知道这个细节，那么估计他对语言也熟悉不到哪儿去；而如果他知道，那么虽然他可能并不是好的程序员，但我们还是能够就后一个问题进一步测试的”，这个理念的问题在于，对语言熟悉到一定程度（什么程度后面会具体建议）就已经可以很好的编程了（剩下的只需查查文档）；而很多公司在测试“对语言熟悉程度”的时候走得明显太远了（比如，问临时对象生命期和析构顺序当然是无可厚非的，但问如何避免一个类被拷贝或者如何避免其构建在堆上？）；当然，有些语言知识是必须要提前掌握的，具体有哪些后面会提到，面试的时候并非不能问语言细节，关键是“问哪些”。

所以说：

事实3：C++的整个生态圈这么些年来在学习C++的哲学上，实在没有多少改善。

为什么？是因为Bjarne介绍的学习方法在技术上没有说到点子上？是Andrew Koenig的书写得不够好？说了谁也不会相信。因为实际上，这里的原因根本不是技术上的，而是非技术的。

众所周知的一个事实是，从最表层讲，C++的最严重问题是在语言学习阶段占用了学习者的太多时间。翻一翻你的C++书架或者电子书目录，绝大多数的C++“经典”都是在讲语言。在我们通常的意义上，要“入门”C++，在语言上需要耗的时间一般要两三年。而要“精通”C++，则搞不好需要耗上十年八年的。（这跟Peter Norvig说的“十年学习编程”其实不是一回事，人家那是说一般意义上的编程技能，不是叫你当语言律师。）

那为什么我说“C++的复杂性是根本原因”是个有漏洞的推理呢？因为，要让人们在使用一门语言去做事情之前耗上大量时间去学习语言中各种复杂性，除了语言本身的复杂性的事实之外，还有一个重要的事实，那就是学习者的态度和（更重要的）方法。而目前大多数C++学习者的态度和方法是什么呢？——在真正用C++之前看上一摞语言书（日常编程八辈子都未必用得到）。而为什么会存在这样的学习态度呢？这就是真正需要解释的问题。实际上，有两方面的原因：

事实4：市面上的绝大多数C++书籍（包括很多被人们广泛称为“必读经典”的）实际上都是反面教材。


也就是说，随便你拿起哪本C++书籍（包括很多被人们广泛称为“必读经典”的），那么有很大的可能这本书中的内容不是你应该学的，而是你不应该学的。我之所以这么说有两个原因，因为一，我曾经是受害者。二，也是更实质性的原因，这些所谓的必读经典，充斥的是介绍C++中的陷阱和对于C++的缺陷的各种workarounds（好听一点叫Idioms（惯用法）或techniques（技术））；又因为C++中的这类陷阱和缺陷实在数不胜数，所以就拉出了一个“长尾”；这类书籍在所有语言中都存在（“C缺陷和陷阱”、“Effective Java”、“Effective C#”等等），然而在C++里面这个尾巴特别长，导致这类书数不胜数。三，这些书中列出来的缺陷和陷阱根本不区分常见程度，对于一个用本程序员来说，应该希望看到“从最常见的问题到最不常见的问题”这样的顺序来罗列内容，然而这些书里面要么全部混在一起，要么按照“资源管理、类设计、泛型”这样的技术分类来介绍内容，这根本毫无帮助（如果我看到一个章节的内容，我当然知道它讲的是类设计还是资源管理，还用废话么？），使得一个学习者无法辨别并将最重要的时间花在最常见的问题之上。

最最关键的是：这些书当中介绍的内容与成为一个好程序员根本毫无关系，它们顶多只能告诉你——嗨，小心跌入这个陷阱。或者告诉你——嗨，你知道当你（八辈子都不一定遇到）遇到这个需求的时候，可以通过这个技巧来得以解决吗？结果读了一本又一本之后，你脑袋里除了塞满了“禁止”、“警戒”、“灯泡”符号之外，真正的编程素质却是一无长进。又或者有这样一类书，热衷于解释语言实现背后的机制，然而语言特性本质上是干嘛用的？是用来在实际编码中进行抽象的（说得好听一点就是“设计”），不是用来告诉你这个特性是怎么支持的。比如我就见过以下的情景：面试官问：“你知道虚函数吗？”得到的回答是一堆关于虚函数表机制的解释。面试官又问：“那虚函数的好处是什么呢？”到底为什么要虚函数呢？得到的回答是：“恩…啊…就是…多态吧”（这时已经觉得回答不够深刻了）。再问：“那多态是干嘛的呢？”哑口无言。

事实5：就算记住一门语言的所有细节也不能让你成为一个合格的程序员。


事实6：了解语言实现固然有其实践意义（在极端场合的hack手法，以及出现底层bug的时候迅速定位问题），然而如果为了了解语言机制而去了解语言机制便脱离了学习语言的本意了。

在C++里面这样的情况很多见：知道了语言实现的底层机制，却不知道语言特性本身的意义在什么地方。本末倒置。为什么？书害的。二，这类书当中介绍的所有情景加起来其实只属于那20%（二八法则），甚至20%都不到的场景（究竟是哪些书，后面会介绍，我不便直接列出书名，打击面太大，但我会把我认为essential的书列出来）。这就是为什么我说“八辈子都用不着”的原因。

事实7：80%的C++书籍（包括一些“经典”）只涉及到20%（或者更少）的场景。

你可能会说，那难道这些书就根本不值得看了吗？

我的回答是，对。根本不值得看。——但是值得放在旁边作为必要的时候的参考（记住从索引或目录翻起，只看严格必要的部分），如果你是个严肃的程序员的话。因为不管承认与否，墨菲法则的强大力量是不可忽视的——如果有一个可能遇到的陷阱，那么总会遇到的。而同样，C++的那些奇技淫巧也并非空穴来风，总有时候会需要用到的。但是你不需要预先把C++的所有细节和技巧存在脑子里才能够去编程，即：

建议1：有辨别力地阅读（包括那些被广泛称为“经典”的）C++书籍。

如果书中介绍的某块内容你认为在日常编程中基本不会用到（属于20%场景），那么也许最好的做法是非常大概的浏览一下，留个印象，而不是顺着这条线深究下去。关于在初学的时候应该读哪些书，后面还会提到。

实际上，除了语言无关的编程修养之外（需要阅读什么书后面会提到），对于C++这门特定的语言，要开始用它来编程，你只需知道一些基础但重要的语言知识（需要阅读哪些书后面会提到）以及“C++里面有许多缺陷和陷阱”的事实，并且——

建议2：养成随时查阅资料和文档的习惯。

“查文档”几乎可以说是作为一个程序员最重要的能力（是的，能力）了；它是如此重要，以至于在英文里面有一个专门的缩写——RTFM。为什么这个能力如此重要，原因很简单：编程领域的知识太鸡零狗碎了。不仅知识量巨大，而且知识的细节性简直是任何学科都无与伦比的（随便找一个框架类库看看它的API文档吧）。所以，把如此巨量的信息预先放在脑子里不仅不实际，而且简直是自作孽。你需要的是“元能力”，也就是查文档的能力——从你手头遇到的问题开始，进行正确合理的分析，预测问题的解决方案可能在什么地方，找到关于后者的资料，阅读理解，运用。

同样，在C++中也是如此，如果你从学习C++一开始就抱着这种态度的话，那么即便等到面试的时候被问到某个语言细节，你也可以胸有成竹的说你虽然并不知道这个细节，但在实际编码中遇到相应问题的时候肯定会找到合适的参考资料并很快解决问题（解决问题，才是最终目的）。当然，更大的可能性是，你在平常编码中已经接触过了最常见的那80%的陷阱和技巧了，由于你用的是实践指导性的学习方式，所以你遇到的需要去学习的陷阱和技巧几乎肯定都是常见场景下的，比没头苍蝇似的逮住一本C++“经典”就“细细研读”的办法要高效N倍，因为在没有实践经验的情况下，你很可能会认为其中的每个技巧，每个陷阱，都是同样概率发作的。

为什么市面上的C++书热衷于那些细节和技巧呢？

你用一个天生用来开啤酒瓶的工具开了啤酒瓶，不但啥成就感也没有，而且谁也不会觉得你牛13。然而，如果你发明了一种用两根筷子也能打开啤酒瓶的办法，或者你干脆生就一口好牙可以把瓶盖啃开，那也许就大不一样了。人家就会觉得你很好很强大。

事实8：每个人都喜欢戴着脚镣跳舞。

也就是说，如果你用一个天生为某个目的的工具来做他该做的事情，没有人会喝彩，你也不会觉得了不起。但如果你用两个本身不是为某个目的的工具组合出新功能的话，你就是“创新”者（尽管也许本来就有某个现成的工具可用）。

而C++则是这些“创新”的土壤，是的，我说的就是无穷无尽的workarounds和惯用法。但问题是，这些“创新”其实根本不是创新，你必须认识到的是，他们都只不过是在没有first-class解决方案的前提下不得已折腾出来的替补方案。是的，它们某种程度上的确可以叫创新，甚至研究可行的解决方案本身也是一件非常有意思的事情，但——


事实9：我知道它们很有趣，但实际上它们只是补丁方案。

是的，不要因为这些“创新”方案有趣就忍不住一头钻进去。你之所以觉得有趣是因为当你一定程度上熟悉了C++之后，C++的所有一切，包括缺陷，对你来说就成了一个“既定事实”，一个背景，一个习以为常的东西（人是有很强的适应性的）。因此，当你发现在这个习以为常的环境下居然出现了新的可能性时，你当然是会欢呼雀跃的（比如我当年读《Modern C++ Design》的时候就有一次从早读到晚，午饭都没吃），然而实际上呢？其它语言中也许早就有first-class的支持了，其它语言也许根本不需要这个惯用法，因为它们就没有这些缺陷。此外，从实践的角度来说，更重要的是，这些“解决方案”也许你平时编程根本就用不到。

不，我当然不是说这些补丁方案不重要。正如前面所说，C++中繁杂的技巧并非空穴来风，总有实际问题在背后驱动的。但问题是，对于我们日常编程来说，这些“实际问题”简直是八杆子打不着的。犯不着先费上80%的劲儿把20%时候才用到的东西揣在脑子里，用的时候查文档或书就行了。

看到这里，塑造C++中特定的心态哲学的另一个原因想必你也已经知道了。实际上，这个原因才是真正根本的。前面说的一个原因是C++书籍市场（教育）造就的，然而为什么人们喜欢写这些书呢？进一步说，为什么人们喜欢读这些书呢？（我承认，我也曾经读得津津有味。）答案很简单：心理。每个人都喜欢戴着脚镣跳舞（事实8）。认识到这一点不是为了提倡它，而是只有当我们认识到自己为什么会津津有味地去钻研一堆补丁解决方案的时候，我们才真正能够摆脱它们的吸引。

总而言之，C++的复杂性只是一个必要条件，并非问题的根本症结。根本症结在于人的心理，每个人都喜欢戴着脚镣跳舞，并且以为是“创新”。意识到这一点之后可以帮我们避免被各种各样名目繁多的语言细节和技巧占去不必要的时间。

然而，C++的复杂性始终是一个不可回避的现实。C++中有大量的陷阱和缺陷，后者导致了数目惊人的惯用法和workarounds。不加选择的全盘预先学习，是非常糟糕的做法，不仅低效，而且根本没有必要，实在是浪费生命。爱因斯坦曾经说过，“我只想知道‘他’（宇宙）的设计理念，其它的都是细节”。然而，正如另一些读者指出的，如果对C++中的这些细节事先一点都没有概念的话，那么实际编码中一旦遇到恐怕就变成没头苍蝇了，也许到哪里去RTFM都不知道。这也是为什么那么多C++面试都会不厌其烦地问一些有代表性的语言细节的原因。

把细节全盘装在脑子里固然不好，但对细节一无所知同样也不是个办法。那么对于C++程序员来说，在学习中究竟应该以怎样的态度和学习方法来对付C++的复杂性呢？其实答案也非常简单，首先有一些很重要&必须的语言细节&特性是需要掌握的，然后我们只需知道在C++中大抵有哪些地方有复杂性（陷阱、缺陷），那么遇到问题的时候自然能够知道到哪儿去寻找答案了。具体的建议在后文。

C++的复杂性分类

本来这一节是打算做成一个C++复杂性索引的，然而一来C++的复杂性太多，二来网上其实已经有许多资料（比如Bjarne Stroustrup本人的C++ Technical FAQ就是一个很好的文档），加上市面上的大多数C++书里面也不停的讲语言细节；因此实际上我们不是缺乏资料，而是缺乏一种索引这些资料的办法，以及一种掌控这些复杂性的模块化思维方法。

由于以上原因，这里并不详细罗列C++的复杂性，而是提供一个分类标准。

C++的复杂性有两种分类办法，一是分为非本质复杂性和本质复杂性；其中非本质复杂性分为缺陷和陷阱两类。另一种分类办法是按照场景分类：库开发场景下的复杂性和日常编码的复杂性。从从事日常编码的实践者的角度来说，采用后一种分类可以让我们迅速掌握80%场景下的复杂性。

二八法则

以下通过列举一些常见的例子来解释这种分类标准：

80%场景下的复杂性：

1. 资源管理（C++日常复杂性的最主要来源）：深拷贝&浅拷贝；类的四个特殊成员函数；使用STL；RAII惯用法；智能指针等等。

2. 对象生命期：局部&全局对象生存期；临时对象销毁；对象构造&析构顺序等等。

3. 多态

4. 重载决议

5. 异常（除非你不用异常）：栈开解（stack-unwinding）的过程；什么时候抛出异常；在什么抽象层面上抛出异常等等。

6. undefined&unspecified&implementation defined三种行为的区别：i++ + ++i是undefined behavior（未定义行为——即“有问题的，坏的行为，理论上什么事情都可能发生”）；参数的求值顺序是unspecified（未指定的——即“你不能依赖某个特定顺序，但其行为是良好定义的”）；当一个double转换至一个float时，如果double变量的值不能精确表达在一个float中，那么选取下一个接近的离散值还是上一个接近的离散值是implementation defined（实现定义的——即“你可以在实现商的编译器文档中找到说明”）。这些问题会影响到你编写可移植的代码。

（注：以上只是一个不完全列表，用于演示该分类标准的意义——实际上，如果我们只考虑“80%场景下的复杂性”，记忆和学习的负担便会大大减小。）

20%场景下的复杂性：

1. 对象内存布局

2. 模板：偏特化；非类型模板参数；模板参数推导规则；实例化；二段式名字查找；元编程等等。

3. 名字查找&绑定规则

4. 各种缺陷以及缺陷衍生的workarounds（C++书中把这些叫做“技术”）：不支持concepts（boost.concept_check库）；类型透明的typedef（true-typedef惯用法）；弱类型的枚举（强枚举惯用法）；隐式bool转换（safe-bool惯用法）；自定义类型不支持初始化列表（boost.assign库）；孱弱的元编程支持（type-traits惯用法；tag-dispatch惯用法；boost.enable_if库；boost.static_assert库）；右值缺陷（loki.mojo库）；不支持可变数目的模板参数列表（type-list惯用法）；不支持native的alignment指定。

（注：以上只是一个不完全列表。你会发现，这些细节或技术在日常编程中极少用到，尤其是各种语言缺陷衍生出来的workarounds，构成了一个巨大的长尾，在无论是C++的书还是文献中都占有了很大的比重，作者们称它们为技术，然而实际上这些“技术”绝大多数只在库开发当中需要用到。）

非本质复杂性&本质复杂性

此外，考虑另一种分类办法也是有帮助的，即分为非本质复杂性和本质复杂性。

非本质复杂性（不完全列表）

1. 缺陷（指能够克服的问题，但解决方案很笨拙；C++的书里面把克服缺陷的workarounds称作技术，我觉得非常误导）：例子在前面已经列了一堆了。

2. 陷阱（指无法克服的问题，只能小心绕过；如果跌进去，那就意味着你不知道这个陷阱，那么很大可能性你也不知道从哪去解决这个问题）：一般来说，作为一个合格的程序员（不管是不是C++程序员），80%场景下的语言陷阱是需要记住才行的。比如深拷贝&浅拷贝；基类的析构函数应当为虚；缺省生成的类成员函数；求值顺序&序列点；类成员初始化顺序&声明顺序；导致不可移植代码的实现相关问题等。

本质复杂性（不完全列表）

1. 内存管理

2. 对象生命期

3. 重载决议

4. 名字查找

5. 模板参数推导规则

6. 异常

7. OO（动态）和GP（静态）两种范式的应用场景和交互

总而言之，这一节的目的是要告诉你从一个较高的层次去把握C++中的复杂性。其中最重要的一个指导思想就是在学习的过程中注意你正学习的技术或细节到底是80%场景下的还是20%场景下的（一般来说，读完两本书——后面会提到——之后你就能够很容易的对此进行判断了），如果是20%场景下的（有大量这类复杂性，其中尤数各种各样的workarounds为巨），那么也许最好的做法是只记住一个大概，不去作任何深究。此外，一般来说，不管使用哪门语言，认识语言陷阱对于编程来说都是一个必要的条件，语言陷阱的特点是如果你掉进去了，那么很大可能意味着你本来就不知道这有个陷阱，后者很大可能意味着你不知道如何解决。

学习C++：实践者的方法

在上面写了那么多之后，如何学习C++这个问题的答案其实已经很明显了。我们所欠缺的是一个书单。

第一本

如果你是一个C++程序员，那么很大的可能性你会需要用到底层知识（硬件平台架构、缓存、指令流水线、硬件优化、内存、整数&浮点数运算等）；这是因为两个主要原因：一，了解底层知识有助于写出高效的代码。二，C++这样的接近硬件的语言为了降低语言抽象的效率惩罚，在语言设计上作了很多折衷，比如内建的有限精度整型和浮点型，比如指针。这就意味着，用这类语言编程容易掉进Joel所谓的“抽象漏洞”，需要你在语言提供的抽象层面之下去思考并解决遇到的问题，此时的底层知识便能帮上大忙。因此，一本从程序员（而不是电子工程师）的角度去介绍底层知识的书会非常有帮助——这就是推荐《Computer Systems：A Programmers Perspective》（以下简称CSAPP）（中译本《深入理解计算机系统》）的原因。

第三本（是的，第三本）

另一方面，C++不同于C的一个关键地方就在于，C++在完全保留有C的高效的基础上，增添了抽象机制。而所谓的“现代C++风格”便是倡导正确利用C++的抽象机制和这些机制构建出来的现代C++库（以STL为代表）的，Bjarne也很早就倡导将C++当作一门不同于C的新语言来学习（就拿内存管理来说，使用现代C++的内存管理技术，几乎可以完全避免new和delete），因此，一本从这个思路来介绍C++的入门书籍是非常必要的——这就是推荐《Accelerated C++》的原因（以下简称AC++）。《Accelerated C++》的作者Andrew Koenig是C++标准化过程中的核心人物之一。

第二本

C++是在C语言大行其道的历史背景下发展起来的，在一开始以及后来的相当长一段时间内，C++是C的超集，所有C的特性在C++里面都有，因此导致了大量后来的C++入门书籍都从C讲起，实际上，这是一个误导，因为C++虽然是C的超集，然而用抽象机制扩展C语言的重大意义就在于用抽象去覆盖C当中裸露的种种语言特性，让程序员能够在一个更自然的抽象层面上编程，比如你不是用int*加一个数组大小n来表示一个数组，而是用可自动增长的vector；比如你不是用malloc/free，而是用智能指针和RAII技术来管理资源；比如你不是用一个只包含数据的结构体加上一组函数来做一个暴露的类，而是使用真正的ADT。比如你不是使用second-class的返回值来表达错误，而是利用first-class的语言级异常机制等等。然而，C毕竟是C++的源头，剥开C++的抽象外衣，底层仍然还是C；而且，更关键的是，在实际编码当中，有时候还的确要“C”一把，比如在模块级的二进制接口封装上。Bjarne也说过，OO/GP这些抽象机制只有用在合适的地方才是合适的。当人们手头有的是锤子的时候，很容易把所有的目标都当成钉子，有时候C的确能够提供简洁高效的解决方案，比如C标准库里面的printf和fopen（此例受云风的启发）的使用界面就是典型的例子。简而言之，理解C语言的精神不仅有助于更好地理解C++，更理性地使用C++，而且也有其实践意义——这就是推荐《The C Programming Language》（以下简称TCPL）的原因。此外，建议在阅读《Accelerated C++》之前先阅读《The C Programming Language》。因为，一，《The C Programming Language》非常薄。二，如果你带着比较的眼光去看问题，看完《The C Programming Language》再看《Accelerated C++》，你便会更深刻的理解C++语言引入抽象机制的意义和实际作用。

第四本

《Accelerated C++》固然写得非常漂亮，但正如所有漂亮的入门书一样，它的优点和弱点都在于它的轻薄短小。短短3百页，对现代C++的运用精神作了极好的概述。然而要熟练运用C++，我们还需要更多的讲解，这个时候一本全面但又不钻语言牛角尖，从“语言是如何支持抽象设计”的角度而不是“为了讲语言特性而讲语言特性”的角度来介绍一门语言的书便至关重要，在C++里面，我还没有见到比C++之父本人的《The C++ Programming Language》（以下简称TC++PL）做得更好的，C++之父本人既有大规模C++运用的经验又有语言设计思想的最本质把握，因此TC++PL才能做到高屋建瓴，不为细节所累；同时又能做到实践导向，不落于为介绍语言而介绍语言的巢臼。最后有一个需要提醒的地方，TC++PL其实没有它看起来那么厚，因为真正介绍语言的内容只有区区500页（第一部分：基础；第二部分：抽象机制；以及第四部分：用C++设计），剩下的是介绍标准库的，可以当作Manual（参考手册）。

建议3：CSAPP &TCPL& AC++&TC++PL。


是的，在C++方面登堂入室并不需要阅读多得恐怖的所谓“经典”，至于为什么这些“经典”无需阅读，前面已经讲的很详细了。其实你只需要这四本书，就可以奠定一个深厚的基础，以及对C++的成熟理性的现代运用理念。其余的书都可以当成参考资料，用到的时候再去翻阅，即：


建议4：实践驱动地学习。

实践驱动当然不代表什么基础都不打，直接捋起袖管就上。不管运用哪种工具，首先都需要知道关于它的一定程度的基本知识（包括应该怎么用，和不应该怎么用）。知道应该怎么用可以帮你发挥出它的正确和最大效用，知道不应该怎么用则可以帮你避免用的过程中伤及自身的危险。这就是为什么我建议你看四本书，以及建议你要了解C++中的陷阱（大部分来自C，因此你可以阅读《C缺陷和陷阱》）的原因。

实践驱动代表着一旦一个扎实的基础具备了之后获得延伸知识的方式。出于环境和心理的原因，C++学习者们在这条路上走错的几率非常大，许多人乃至以上来就拿Effective C++&More Effective C++、Inside C++ Object Model这类书去读（是的，我也是，所以我才会在这里写下这篇文章），结果读了一本又一本，出现知道虚函数实现机制的每个细节却不知道虚函数作用的情况。

实践驱动其实很简单：实践+查文档。知识便在这样一个简单的循环中积累起来。实践驱动的最大好处就是你学到的都是实践当中真正需要的，属于那“80%”最有用的。而查文档的重要性前面已经说过了，但对于C++实践者来说，哪些“文档”是非常重要的呢？

第二本

《C++ Coding Standard》。无需多作介绍，这是一本浓缩了C++社群多年来宝贵的经验结晶的书，贴近实践，处处以80%场景为主导，不钻语言旮旯，用本为主…总之，非常值得放在手边时时参阅。因为书很薄，所以也不妨先往脑袋里面装一遍。书中的101条建议的介绍都很简略，并且指出了详细介绍的延伸阅读，在延伸阅读的时候还是要注意不要陷入无关的细节和不必要的技巧中，时时抬头看一看你需要解决的问题。在C++编码标准方面，Bjarne也有一些建议。

第一本

《The Pragmatic Programmer》，用本程序员的杰作；虽然不是一本C++的书，但其介绍的实践理念却是所有程序员都需要的。

第三本

《Code Complete, 2nd Edition》，这是一本非常卓越的参考资料，涉及开发过程的全景，有大量宝贵的经验。你未必要一口气读完，但你至少应该知道它里面都写了哪些内容，以便可以回头参阅。

其它

所有优秀的技术书籍都是资料来源。一旦养成了查文档的习惯，所有的电子书、纸书、网络上的资源实际上都是你的财富。不过，查文档的前提是你要从手边的问题分析出应该到什么地方去查资料，这里，分析问题的能力很重要，因此：

建议5：思考。

这个建议就把我们带到了第四本书：

第四本：

《你的灯亮着吗？》。不作介绍，自己阅读，这本书只有一百多页，但精彩非常，妙趣横生。

最后，要想理性地运用一门语言，不仅需要看到这门语言的特点，还要能够从另一个角度去看这门语言——即看到它的缺点，因为从心理上——

事实10：一旦我们熟悉了一门语言之后，就容易不知不觉地在其框架下思考，受到语言特性的细节的影响，作出second-class的设计。

对于像C++这样的在抽象机制上作了折衷的语言，尤其如此，思考容易受到语言机制本身细节的影响，往往在心里头还没想好怎么抽象，就已经确定了使用什么语言机制乃至技巧；更有甚者是为了使用某个特性而去使用某个特性。然而，实际上，我们应该——

建议6：脱离语言思考，使用语言实现。

关于设计的一般理念，Eric Raymond在《The Art of Unix Programming》的第二部分有非常精彩的阐述。

此外，除了脱离语言的具体抽象机制来思考设计之外，学习其它语言对同类抽象机制的支持也是非常有益的，正如老话所说，“兼听则明”。前一阵子reddit上也常出现“How Learning XXX help me become a Better YYY programmer”（其中XXX和YYY指代编程语言）的帖子，正是这个道理，这就把我们带到了最后一个建议：学习其它语言。

建议7：学习其它语言。

如果你是一个系统程序员，你可能会觉得没有必要学习其它语言，然而未必如此，你未必需要精通其它语言，而是可以去试着了解其它语言的设计理念，是如何支持日常编程中的设计的。这一招非常有利于在使用你自己的语言编程时心理上脱离语言机制细节的影响，作出更好的抽象设计。

尾声

建议8（可选）：重读本文。

注：这篇文章的目的是给国内的C++学习者（尤其是初学者）一个可操作的建议。我打算不断修订并完善它；因为这是根据我个人的经验来写的，而基于我对C++的熟悉程度，可能会有地方并不能完完全全站到初学者的视角来看问题。我估计会有这样的地方，所以，如果有任何建议，请发邮件给我：pongba@gmail.com





]]> http://jackxiang.com/post//#blogcomment <user@domain.com> Thu, 01 Jan 1970 00:00:00 +0000 http://jackxiang.com/post//#blogcomment