C\C++编译器的未来.我们还需要C++么?

文章出处：
http://my.oschina.net/sw23120/blog/119584

在未来我们还需要纯C++开发模式么?

随着C++11的诞生,C++已经越来越臃肿,从03的时候就觉得C++实在是太复杂了。以一个合格C++程序员的标准来简单的来说3-5年略有小成,5-8年才可以说自己是个合格的C++程序员,10年以上才敢到处和别人说自己精通C++,不至于被某人用个很bt的问题问倒。C++程序员的培养成本太高了。

随着技术的发展与进步，还有产品的复杂性，导致了开发开始走了多样性，谁都想更快的开发速度，更好的质量。于是混合开发已经是不少公司采用的方案了。使用python,ruby,java,php才高层开发，性能瓶颈采用c来开发.这个更适合当今的开发方式。需要用到C++的地方越来越少。

C++程序员一直引以自豪的是C++可以拥有OO的控制能力，又同时拥有C的性能。C++诞生于80年代，当时的硬件性能的确不行，进入21世纪后随着硬件技术的不断发展，现在Java为代表的虚拟机或者动态语言开发更加成为主流平台。企业级开发中C++的份额越来越少，与C+汇编相比底层开发，C++由于资源占用和过于复杂的结构导致了在系统底层开发也不占据优势。(比如操作系统,驱动,单片机,嵌入式等领域.C++其实很少用,即使用了也是简单的OO包装,几乎不会使用stl等高级特性)甚至连linux都完全不用C++开发内核.

C++的几大问题.

1.运行速度和占用资源:目前来说C++的运行速度和资源占用肯定比C是高许多.而且特性越多C++编译程序的规模也越来越大。编译速度也是一个非常大的问题，一编译好几十分钟的工程也不是罕见的事情

2.移植性和扩展性:许多小型嵌入式平台根本没有C++编译器或者没有完整的支持C++特性的编译器.对于一般公司和个人来说维护C编译器是可以做到的，可是维护一个C++编译器那是根本无法想象的。而且C++虽然有标准可是二进制兼容性和各种参数传递方式却没有一个统一的标准，与此相比C就完全没有这个问题。

3.人员,开发,调试,管理成本:许多时候不需要极限性能的产品(如果需要也不会用C++而是上fortran之类的语言)C++的程序员价格很高,而且由于C++实在过于复杂导致了老人走了新人拿着代码无法维护的事情频频发生.而且现在python,ruby,lua等动态语言的兴起C++缓慢的开发速度与之相比相当没有性价比,更多的人开始流行C+Python(Lua,ruby)的开发模式.需要性能的地方用C开发,加上Python,Ruby先进的包管理,更加完善的面向对象支持和各种语法糖C++越来越没什么必要了…而且开始i有工程直接把Python,Ruby输出为C语言或者干脆成为一个编译器也不是不可能的.而且各种比Java更加优秀的Jit诞生后，C模块调用成本也相当低，甚至可以完全和C++相媲美。在调试和测试的成本低廉的情况下，C++的成本的确是让人值得思考是否值得使用。

4.真正需要C++工程:当然许多人觉得游戏引擎呀，各种底层的引擎呀还是需要C++的，以第三条为例，游戏引擎以后越来越多的走向快速开发和制定化，模块拆分自然也是必然的。C构造底层(包括python转换成c也算进去)自然可以应用的上。而且游戏现在越来越偏向于脚本化，毕竟引擎不是每个人都需要去修改，大部分人只是学习如何使用就可以了，Lua\Python+一个合适的Jit性能就完全可以保证了。

基于以上这四条，以后我们还有必要使用C++么？C++框架相当少，找来找去也就是那几家大型商业公司，微软（不具备跨平台性），Intel（不支持ARM，MIPS等其他），GCC（一般人难以扩展，即使5.0出来后也未必是一般公司有扩展能力的），LLVM（同GCC一样，过于庞大，而且优化度和未来如何发展还是个问题）。而C编译器几乎一般公司都有能力维护，甚至一个人都可以维护。(lcc,pelles c,tcc等许多许多c编译器)

有人说有人有维护编译器的必要么？远的不说就说近的吧，越来越的移动处理器出现在市面上，各家IP虽然都用的是Soc的但是各种优化和特殊指令还是有的。例如君正的JZ系列，ARM的各种处理器也是有自己的特殊指令的。那对于芯片厂商和平台，中间件等第三方厂商来说。能够直接在CPU中添加硬件加速和软件直接利用硬件指令当然是效果最好的。那么未来还有必须要使用C++这种成本很高的编程语言么？当然也许不能完全否定，但是目前C++的地位的确是越来越下降。再加上各种成本，C++的前途很值得担忧。

好奇号250w行C代码，100w行手写(以此来看C不是不能开发大型工程,大型工程重要的是设计而不是语言,设计模式也不是OO的专利)，其余的都是靠自动化工具生成，即使换上特殊的CPU，自己重写codegen函数也是一两个人完全可以做到的。可是反观C++，那种规模的编译器我想绝对不是一两个人可以维护的了的。ruby,python的编译器也都是基于c写的。luajit虽然不成熟但是带来的优化性能让我们看到了，轻量级语言其实还是具有可观的性价比的。那剩下的问题就仅仅在于call的性能了。小函数有必要，大的函数其实inline看不出什么性能的提升。而且也完全可以依靠动态语言jit的优化来解决这个问题。高级动态语言JIT速度一般不行的原因也在于函数太大和全局优化在“即时”情况下还是不足以做到很完善的优化。当然了小一点的函数还是可以做的挺好的，而且随着编译器技术的发展，这种问题肯定也会得到有效的解决，实在不行还能直接生成C代码，再用C编译器进行交叉编译。

为此我从两年前就开始做了一种尝试，自己开发底层asm,c的交叉编译器(前面说过了个人维护asm,c的交叉编译器还是可以做到的C++就不是一个人可以扛得住的了).目前做的就是使用c语言重构fasm和Ansi c交叉编译器，然后是基于Ansi c的跨平台界面库和一种轻量级动态语言的JIT。以此为中间件来开发以后的程序。

当然其中还会遇到许多难题，但是都是可以解决的。技术在发展，程序设计也在发展，一些老的不必要的传统也可以放弃了。至少在个人看来C++完全可以被前面介绍的开发模式替换掉。更轻量级，更简单的交叉编译器。

当然了go语言也是一个不错的选择，虽然他还是有许多问题。以后等技术成熟和有足够的资源的时候会尝试开发一个跨平台的Rad工具(个人很喜欢delphi可是它不跨平台。而且许多特性也满足不了轻量级需求，但是它很优秀)