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