再谈C++

(兼答复《C++不是万能的》一文后面的评论)

参与这次C++的大讨论纯属巧合,本来我那天是去跟sunway讨论的模式的问题,顺便谈到C++,结果没过两天就碰到这次大讨论。

其实我一向是不太愿意参与语言之争的,因为不同的语言各有所长,很难说谁比谁好。如fastzhao所说,“只是个信仰的问题”。但是这次我还是掺和了,原因就在于Kakurin要把自己的信仰强加于Torvalds。在Kakurin们看来,C++就是万能的,Torvalds不用C++是不对的,但我不这么认为,所以我要掺和。

就 我自己来说,虽然算下来从开始用C++至今也有十一年了(用C还要早一年),但最近已经好几年都没有怎么用过C和C++了,最多就是偶尔自己写一些小程序 玩的时候会用到C++。但是像云风、sunway和令狐这些人就不同了,他们几乎每天都在和C/C++打交道。因此在我看来,他们的看法是很有意义的。而 在这次争论中,大部分支持Kakurin的人对于C++的理解远未达到他们的程度,看他们把Bjarne或标准委员会祭出来,我只觉得可笑。

一个人所处的位置决定了TA看问题的角度

就在与sunway讨论的第二天,我陪同台湾的一位摄影大师逛上海,老人家在路上指点我一些摄影的法门,其中就有这么一点。大师让我自己通过取景器看一下,向前或向后一步,向左或向右一步,得到的景象就是会有很大的不同。

脱离位置来谈问题就是空谈。所以在我在前文里反复强调,对于Torvalds的Git以及云风或sunway他们的项目来说,C++并不总是最合适的。

不可否认,C++的很多feature都是很好的东西,单是一个template就让多少别的语言用户馋得流口水。但是并不是说C++具有所有C(旧版)的feature并提供更多的可能性,用C++就一定更好。举一个最简单的一个例子:在C里,一句“a=b+c;“,每个C程序员都可以理解,并且通常不会有什么误解,对于C高手来说,甚至可以一眼看出目标代码会是什么样的。但是在C++里呢?谁知道加号有没有做过运算符重载。

如duyanning 和laibach0304所说,既然用了就要了解,这是没错。但这只是站在一个Coder的位置上来看,而作为一名leader,却不可能要求team里 的每一位成员都能做到。dick_song说leader在分配人员的时候就应该知道成员加以区分适当使用,但作为公司特别是软件公司来说,压低人力资源 成本是很重要的,所以leader能用到什么水平的人,其实也没有什么决定权。

更何况在实践中,有些问题并非是教科书上说的那么简单的,特别是在团队开发中。 再举一个比较特殊的例子:令狐曾经碰到一个C++初始化列表的问题,这个问题如云风在回复里说的修改基类的方法应该是最规范的C++解决方法,但是在令狐 这个例子中却不行,因为那个基类是另一个团队写的,他没有权力修改,所以最后我只能建议他用多重继承的变通方法解决。是的,多重继承是不应该用的,这种情 况下设计是有问题的,但是这又如何呢?团队开发就是这样的,受制于很多非技术性因素

duyanning说他想不出有适合C而不适合C++的地方。如果是我自己一个人做一个项目的开发,我的确也很难想到有什么适合C而不适合C++的地方。但是如果是一个团队呢?想不出其实只是因为碰到过的状况还不够多

dogdotnet说的没错,C++只有少数优秀的程序员能够驾驭,但是软件公司要的是生产效率,等不及公司的所有程序员都成长为优秀的程序员,在他们还没有成长起来之前写出来的C++代码不但没有效率,更没有质量。

就我用过的几种主流语言来说,C++无疑是最接近万能的但是“能”并不意味着“好”。比如说tuple吧,boost里也有tuple,但是跟python简单直接的tuple相比,boost的tuple则明显面目可憎。

刘未鹏在《为什么C++》说得不错,只要谨慎地使用C++,它的确能为我们提供更多可能性。你可以要求自己谨慎并尽可能做到,但是对于团队中的leader,你最多只能要求成员们谨慎,但他们能做到什么样的程度却是个未知数——当然有很多管理方法可以在一定程度上加以控制,比如Code review,但对于公司来说,这又会增加开发的成本。

对了,就是成本!

对 于一个单打独斗的程序员来说,所有成本就是自己,所以C++带来的好处都是实实在在的好处。但是对于一个团队来说,会有很多额外的成本要考虑,比如训练团 队成员达到某个水平所需要的成本,比如Code review的成本,比如某个成员对C++某个特性的误用造成的修改成本……C++的高级特性带来的好处是不是足够补偿这些成本?

综合所有的成本考虑,作为leader可能就不得不在团队中限制使用C++的高级特性,甚至于在某些极端的情况下需要使用C,这也就不足为奇了。

(计划下周一发CSDN,有意见快提^O^)