神话与谬误：争论C 前你应当知道什么

文章作者 100test 发表时间 2007:10:24 14:07:47
来源 100Test.Com百考试题网

　　哈雷将军的笑话想必大家都听过。一句话经口口相传，每个人都根据自己的主观意念加以润色，修补，歪曲…到最后就面目全非。这里最关键的一环就是主观意识，在历史学里面有这么一句话，大致意思是历史其实只存在于人的意念之中.就算完全客观的事件，通过不同的人的嘴说出来，造成的心理效应也往往不一样，每个人都会加上那么一两个形容词，驾驭语言能力高的更是能够舌绽莲花，而语言本就有自身的力量，其中的遣词造句对读者构成的心理影响力便应运而生。甚至于同一句话，用不同的语气说出来，都会造成不同的效果。同一句话，站在不同的立场上看，也会根本不是同一个意思。比如“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都列出来，你也会发现，其实它们几乎每一个都对应了至少一个实际应用。而实际应用需求哪来的?库设计的需求。但归根到底，是使用库的人——终端程序员——的需求。(效率、灵活性、抽象表达力，哪一样不是终端程序员的实际需求呢?)