C\C++编译器的将来.咱们还须要C++么?

  在将来咱们还须要纯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但是它不跨平台。并且许多特性也知足不了轻量级需求，可是它很优秀)