再谈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^）