我本来就《C++不是万能的》一文写了一个续篇，令狐提醒我说：
C++作为一种语言，它拥有任何特性都是没有问题的，并不存在什么“多余的特性”一说。从这个角度上说，C++标准委员会的一切努力都是有意义的。因为它们是在完善C++语言本身。
但是，作为项目开发来说，开发语言并不是唯一的决定因素。没有必要将语言限制在仅使用C++上。在这种背景之下，其它几种语言的组合，可能会比单一使用C++，来得更好。尤其是像C++这样，编译器对标准的实现都未必完整和正确的复杂语言，使用那些过于“高级”的特性其实是会带来风险的。事实上，很多公司在实际使用C++的时候，都会或多或少的通过代码规范进行一些裁减，减少那些“C++高级特性”的使用。
谈这个问题的时候，理论归理论，实践归实践，这样比较好。把语言特性、语言本身发展的争论和语言在项目中应用的争论放到一起，很容易把自己都绕进去的。
我醒悟过来，的确是有些不妥，于是改写成现在这一篇，主要是作为对上一篇中一些评论的回复。
如fastzhao所说，语言问题在大多数时候“只是个信仰的问题”。只是这一次在于Kakurin要把自己的信仰强加于Torvalds。在Kakurin们看来，C＋＋就是万能的，Torvalds不用C＋＋是不对的，但我不这么认为，所以我就掺和了。
祭出Bjarne或标准委员会是一件很可笑的事情，因为正如令狐所说——语言本身和语言的应用是两回事，Bjarne等大师们考虑的是语言本身的问题，我们考虑的应用的问题。
一个人所处的位置决定了TA看问题的角度。脱离位置来谈问题就是空谈。所以在我在前文里反复强调，对于Torvalds的Git以及云风或sunway他们的项目来说，C＋＋并不总是最合适的。他们都是经验丰富的开发专家，在语言的应用层面，考虑得比Kakurin们要全面得多。
不可否认，C＋＋的很多feature都是很好的东西，单是一个template就让多少别的语言用户馋得流口水。但是并不是说C＋＋具有所有C（旧版）的feature并提供更多的可能性，用C＋＋就一定更好。举一个最简单的一个例子：在C里，一句“a=b+c;“，每个C程序员都可以理解，并且通常不会有什么误解，对于C高手来说，甚至可以一眼看出目标代码会是什么样的。但是在C＋＋里呢？谁知道加号有没有做过运算符重载。
如duyanning 和laibach0304所说，既然用了就要了解，这是没错。但这只是站在一个Coder的位置上来看，而作为一名leader，却不可能要求team里 的每一位成员都能做到。dick_song说leader在分配人员的时候就应该知道成员加以区分适当使用，但作为公司特别是软件公司来说，压低人力资源 成本是很重要的，所以leader能用到什么水平的人，其实也没有什么决定权。
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，这也就不足为奇了。
语言本身主要是一个技术问题，而语言的应用则需要面对更多技术以外的问题。