无法确定的未来

时至两年之前，我尤然对C++在游戏开发中的绝对地位感到深信不疑，然而，这两年来，突然感觉到一股寒意……或者我还能保持自信，告诉自己那是冬天带来的寒冷，但潜意识中，却开始相信，传统C++的地位已经开始受到挑战，或者用一种乐观的语调说：

有更多的空间，可以让我们放开去探索了！

带来这个疑问的第一个因素是.net平台。.net是一个更好的COM（野猪语），COM是一个更好的C++（Don Box语），那么，按照传递原则，其实.net是一个更好的C++。

既然如此，为何要那么排斥.net呢？这是去年开始接触.net后的唯一感受。.net比C++好的地方并不简单是因为GC，而是因为编译期可以做更多的事情，这比起写一堆C++宏的可读性要好很多。本来嘛，编译期明明就知道的事情，为什么一定要让我们用宏和模板去偷取？这让人很~不爽！.net由于其特点，因此也可以在编译期做更多的事情了，这样对于一些特殊的要求（譬如自解析的Property Grid），就很容易了。

带来这个疑问的第二个因素就是C++0X自身，添加GC的方式是多种关键字的引入，这个首先就有点让人望而却步，因为这引入了一个跨版本的问题。其次，跨平台的硬伤还是没有解决，CWrapper还是得做，C++Wrapper还是浮云，再次，新C++究竟能在多大程度上，引入相当于.net或者Java的类库，这还是一个问题，Boost再强大，也还不过是一个Boost，而.net的扩展性也开始慢慢显现出来，那么，传统C++的优势还能够体现在哪里？

另外的，最近所作的几个工程，全部都是使用了多语言相互配合编程，纯C++ 配合CLI，纯C++配合CLI配合C#配合Python，这些都很有趣，而且只需要经过很短的培训，就能确实地提高编码效率。

C++并非没有优势，她的优势是效率，C++并非没有劣势，她的劣势在于标准和库，这是C++之父无数次提到的悲剧。在效率可以不那么作为第一因素的前提下，很多事情确实可以绕个近路办理。

当然，如往常一样，本文并不想引起什么纷争，C/C++还是我最为钟爱的语言，因为她纯粹。甚至我自己如果写程序，首先考虑到的决不会是CLI Wrapper和COM Wrapper，而一定是把我自己的程序做成C Wrapper，因为这样能支持更多的语言（理论上）。

但是，这并不意味着一切就可以就此止步，引擎中20%的代码是为了效率，但还有80%的代码是为了方便，这20%的致命一层，目前仍然必须借助C/C++进行呵护，而那80%的工具、编辑器、框架，或许我们更应该为用户考虑，用户方便，那就是方便，用户痛苦，那就是痛苦。有时候，在这个层次上，C++的表现确实是一场灾难。那么，如果有更灵活的语言，为什么不去尝试呢？

灵活的空间大了，或许是好事，或许是坏事，但总而言之还是好事——对于历史的前进而言。

生于语言范式的征途，死于语言范式的沙场，谁让这就是程序员的宿命呢？而谁会没有自己的宿命呢？更多的空间，也有更多的责任。

期待着一个最终解决方案的来临，然在那之前，还需要继续前进。