我看见的那份C++

园子里语言之争又热了起来,我想不知天高地厚的说一下我所理解的C++.

首先应该定下一个论调,C++之父Bjarne Stroustrup在谈及C++的设计和演化时说到,”计算机和程序设计语言可以被当做是一种艺术性的工作,但审美主义因素应该是去辅佐或提升其有用性,而不是取代或损伤它.”,这段真知灼见客观而不偏激,相信赞同的人还是多数的.对一门语言,无论是拥护还是批判,出发点首先应该是爱之深或是责之切,光是动动嘴皮,挑起一滩浑水,是很不负责的.而在两种语言之间,比较很少是公平的,更多时候纯粹是无意义的.要做到公允,评论者应当不偏不倚,但局限于个人的认识,我们总是无知且不自觉地偏向于某个特定的领域,某种风格的程序设计或是程序员社区中的某种文化.

对C++的攻击主要集中在C++的存储管理上,而这些攻击更多地集中在C++缺乏一种有效的垃圾收集机制..也许,垃圾收集是C++所剩无几的可能加入还没有加入的特性了.其实,垃圾收集机制的确是一种很不错的思想,对用户而言,它能够简化设计,让库的设计和构造更加简单,而且可以排除掉许多错误的根源;对多数应用而言,垃圾收集比人肉存储管理更为可靠.但是,垃圾收集机制也不是尽善尽美的,它可能会导致

1. 严重的空间浪费和时间开销,例如极端情况下的多米诺效应般的缺页导致的内存抖动.
2. 垃圾收集机制的实现和移植将带来不可避免的复杂问题,例如某些垃圾收集方案可能提出了对对象布局和对象创建的一些限制.
3. 一些隐含着服务中断的垃圾收集技术将使得C++不合适做许多低层次的工作,比如实时应用,设备驱动程序,操作系统内核上,而这却是C++的一大应用领域.

够了,已经有充分多的论据可以反对这种观点:每个应用在有了垃圾收集机制后悔变得更好.但是,也有足够多的证据可以反对另一种观点:没有那个应用因为有了垃圾收集机制而做得更好.Bjarne Stroustrup得到的一个结论是,”从原则上和可行性上,垃圾收集都是必须的.但是,对于今天的用户,普遍的C++使用和硬件,我们还无法承受将C++的语义和它的基本库定义在垃圾收集系统之上的负担.”当然,这段话是Bjarne Stroustrup在上古时代1994年说的了,我们并不清楚Bjarne Stroustrup至今是否仍旧这么认为的.至少,对多数程序员来说,垃圾收集实在是太有用了,它可以解放我们的心智,让我们的天赋脱离细节的纠缠,真正的将精力用在思想的历练和设计的考虑之上.

前面仅仅是一个C++新特性缺位的小例子,还有的一个例子可以是内置的数据库支持.实际上,为了公正的评价C++,我们应该看到它的设计目标:抽象.Java和C#的大行其道足够说明,这一设计目标本身是没有什么问题的.C++可以被看做是为了描述模块化而做的一种C的扩充,它并不是一门全新的试验性语言,而是一个几乎与C兼容的C的超集.Stephen Jay Gould说,任何纽带的连接力都比不上遗传链.为了兼容,C++继承了太多C的污浊,为了效益它也无法抛弃C的危险的丑陋的某些特性.这就使得C++的设计尽管解决了C的某些问题(Dennis M.Ritchile语),却又保留了C的一些问题.C++的过度设计和过度优雅多多少少有点宗教上的形而上了,它带给程序员的负担太多,而带来的新的思维方式又太少.比如说,D&E这本书让我觉得,为了抽象,C++被模板搞得支离破碎,更显艰涩难懂;而且C++的抽象一味强调了OO,这样的一味偏重将阻挡我们的视野,实际上,抽象就是为了看清本质,OO不是唯一的,function programming的想法也是相当不错的,这就限制了我们在更高维度上的思考,总的来说,我们可以说,C++迈出了很重要的一步,但对当代的设计架构来说,这一步又显得太小了.这样说也许有点强人所难了,但是,C++毕竟只是一门工具,尊重点说,它是无数牛人的智力产物,但是,时代总是在进步的,语言也是在进化的,我们没有必要抱残守缺,增长见识比起无端争论来的更为实际.

<The Practice of Programming>的作者Rob Pike在<Systems Software Research is Irrelevant>一文中痛斥当下操作系统的固步自封,不思进取.我不敢说C++是不思进取的,但是,正如Bjarne Stroustrup说的那样,C++语言和它背后的设计理念,编程思想本身是不会演化的,真正演化的是C++用户对于实际问题的理解,以及我们对于为了帮助解决这个问题而需要的工具的理解..对于C++这门语言来说,它已经太过庞大太过复杂了,所有的修改都需要经过极为谨慎的考虑,而特性的添加更是令人心惊胆颤.也许,C++已经开始走向了封闭,它只是一种选择的桥梁,远远不是一个完美的答案.

最后,上面的废话无非就是一种废话,还是希望自己用好C,用好C++.