C++0x不一定是利好，仅仅掌握C++已经不够了

       最近一直在关注C++0x，看到孟岩老师的一篇blog：“C++0x草案将于年内发表，C++即将重大升级 ”（http://blog.csdn.net/myan/archive/2007/02/08/1505598.aspx），看来C++0x的进展很顺利。C++0x确定要增加垃圾收集机制了！垃圾收集是我盼望已久的特性了，但是我看到这个消息之后，并没有感到高兴，其实我很担心C++增加了垃圾收集之后会变得更复杂！说心里话，我最希望的C++的改进就是简化，但这也是最不可能的改进。C++诞生之初就背着和C兼容的包袱，C++可以再增加更高级的语言特性，但是因为历史原因，C++无法放弃旧任何特性，无论它们是好是坏。这使得C++编译器实现难度也越来越大，编译速度…，唉。我想C++0x增加这些东西的主要目的还是要增加开发效率，这并不是对每一个C++程序员都能成功。特别是对那些新人，门槛又提高了。

 

       语言孰优孰略的争论是没有意义的，一个项目选择使用什么语言，需要根据项目的需要，团队的技能，目标平台的要求等等诸多因素来确定。记得前几年国内的游戏制作论坛就针对C还是C++更合适游戏开发展开过激烈的争论。当时大家主要考虑的就是效率因素。对于游戏程序员来说效率就是生命，Michael Abrash在他的《Graphics Programming Black Book》中谈到程序优化时，精确到了计算时钟周期的程度，甚至考虑到了内存刷新周期！(Chapter 4 In the Lair of the Cycle-Eaters, Dynamic RAM Refresh: The Invisible Hand)。那个时代毕竟已经过去了，现在的PC拥有1GHZ的CPU已经是很平常的事了。大师在谈到优化时也一再强调最有效的优化是算法优化。而现在，C#，Java借助JIT能够把性能损失尽量减少，MS甚至宣称JIT产生高度优化的本机代码执行速度高于C++代码。

       除了效率，项目的风险和开发效率越来越受到大家的重视。C++在团队开发上，的确是风险最高的（推荐看一下Alistair Cockburn，《OO项目求生法则》）。我过去的7年职业生涯全部花在了两个C++项目上，单个的规模都超过20万行。我不象很多热衷于C++的人，我可以说很多时候开发这种项目是很痛苦的。即使我们建立了编程规范，很多人已经习惯了C++的某种编程模型，或者用法，经常把代码搞成各种写法的展览。更大的问题是大家对C++的掌握程度也参差不齐，很多人在基础观念上存在这样那样的错误，而且这种问题正在加剧――招聘到熟练使用C++的人越来越难了。在实际编程中，比内存泄漏更严重的问题就是内存访问越界，这种问题难以跟踪。如果经常有人范这样的错误，就会使大家士气低落。所以从风险角度，从开发效率，从团队合作角度看，C++是需要尽量避免的选择。在过去，对于游戏项目来说，这是无法避免的，现在形势已经开发变化了。

 

       回来谈C++0x，如果我想得到开发效率的大幅度提高，如果我想使用垃圾收集，如果我想要更方便更强大的库，我不会选择使用一个越来越复杂的C++，我会选择另外一个新的语言（平台），Java，C#都是很好的选择，甚至上层使用Python最近也在游戏业开始流行起来。一些成熟的游戏引擎，实现了自己的脚本语言，这种开发模式已经证明是成功的，典型的案例就是Epic的Unreal系列。所以C++可以搞它擅长的部分，例如游戏的图形引擎，AI，物理模拟，这些都对效率要求都非常高，而上层的游戏逻辑，界面我们为什么不选择一种更高级的语言呢？

 

       最近CSDN上还有一个热门话题，“C语言已死”！我觉得这种说法是很可笑的。C/C++确实不如以前热门了，但是它们真的会消失吗，起码现在还看不到这种迹象，特别C，C++死了C都不会死的！你看看操作系统是用什么语言写的就知道了。至于C++，如果你真的了解C++社区，你就会知道现在有多少项目是使用C++的，多少公司的代码库，多少开源的项目都是C++的，过去这么多年的积累不会一下子灰飞烟灭！C++仍然有它的用武之地！有位朋友跟我说世界上最牛X的东西都是一两个人写出来的！C/C++在底层开发的地位是无法动摇的。

 

面对当前的局面，很多游戏项目都开始选择混合语言编程。所以，作为一个程序员，如果想全面发展的话，除了C++还应该掌握至少一种高级语言。