在未来我们还需要纯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可是它不跨平台。而且许多特性也满足不了轻量级需求，但是它很优秀)
引用来自“七液”的评论
引用来自“YU_YU”的评论
语言争论真的是很多很多，但可以归根结底，是由于人之3~5年所学，不希望别人轻易否定过时或者不行，这不就等于在否定这个人么？其实，C++能活到现在还前三（至少也是有科学依据的，对吧），一是历史遗留，二是确实有过人之处，正所谓，可恨之人必有可敬之处。
现在C++的问题，不在于其庞大，因为你尽可以选择自己喜欢的部分，而不需要求全。C++的问题还在于教学上，现存的C++er几乎都是从C学过来的吧，这样说来，使用C++的方式还是C的方式，C++支持多范式，从前面的讨论就可以看出来，class+template，是的！这才是基于对象而非面向对象的方式之一。
C++语法是比其他语言多，这也正是他的优势之一，C++可以让我们可以玩，其他语言能玩吗？虽然这句话很偏激，老板也不会喜欢！
语言是配料，不是工具！配料决定了设计方式，所以，语言会决定设计！从而影响更多后续。这也就解释了为什么很多人觉得C++的开发效率和可维护性很差--那是因为你的思维方式不同啊！
好吧，C++并不适合OO，这是OO的局限和C++的局限共同造成的，C++发展到今天，并不是庞大了，而是越来越合理，不过C++走在一条很荆棘的路上，既要能实现合理的抽象，满足变化，也还要高效的实现效率（设计效率、编译效率、运行效率），这，真惨！不过，生命在于折腾，不是吗？
引用来自“YU_YU”的评论
语言争论真的是很多很多，但可以归根结底，是由于人之3~5年所学，不希望别人轻易否定过时或者不行，这不就等于在否定这个人么？其实，C++能活到现在还前三（至少也是有科学依据的，对吧），一是历史遗留，二是确实有过人之处，正所谓，可恨之人必有可敬之处。
现在C++的问题，不在于其庞大，因为你尽可以选择自己喜欢的部分，而不需要求全。C++的问题还在于教学上，现存的C++er几乎都是从C学过来的吧，这样说来，使用C++的方式还是C的方式，C++支持多范式，从前面的讨论就可以看出来，class+template，是的！这才是基于对象而非面向对象的方式之一。
C++语法是比其他语言多，这也正是他的优势之一，C++可以让我们可以玩，其他语言能玩吗？虽然这句话很偏激，老板也不会喜欢！
语言是配料，不是工具！配料决定了设计方式，所以，语言会决定设计！从而影响更多后续。这也就解释了为什么很多人觉得C++的开发效率和可维护性很差--那是因为你的思维方式不同啊！
好吧，C++并不适合OO，这是OO的局限和C++的局限共同造成的，C++发展到今天，并不是庞大了，而是越来越合理，不过C++走在一条很荆棘的路上，既要能实现合理的抽象，满足变化，也还要高效的实现效率（设计效率、编译效率、运行效率），这，真惨！不过，生命在于折腾，不是吗？
其实，C++能活到现在还前三（至少也是有科学依据的，对吧），一是历史遗留，二是确实有过人之处，正所谓，可恨之人必有可敬之处。
现在C++的问题，不在于其庞大，因为你尽可以选择自己喜欢的部分，而不需要求全。C++的问题还在于教学上，现存的C++er几乎都是从C学过来的吧，这样说来，使用C++的方式还是C的方式，C++支持多范式，从前面的讨论就可以看出来，class+template，是的！这才是基于对象而非面向对象的方式之一。
C++语法是比其他语言多，这也正是他的优势之一，C++可以让我们可以玩，其他语言能玩吗？虽然这句话很偏激，老板也不会喜欢！
语言是配料，不是工具！配料决定了设计方式，所以，语言会决定设计！从而影响更多后续。这也就解释了为什么很多人觉得C++的开发效率和可维护性很差--那是因为你的思维方式不同啊！
好吧，C++并不适合OO，这是OO的局限和C++的局限共同造成的，C++发展到今天，并不是庞大了，而是越来越合理，不过C++走在一条很荆棘的路上，既要能实现合理的抽象，满足变化，也还要高效的实现效率（设计效率、编译效率、运行效率），这，真惨！不过，生命在于折腾，不是吗？
引用来自“ichenshy”的评论
引用来自“七液”的评论
引用来自“ichenshy”的评论
引用来自“七液”的评论
引用来自“MatrixC”的评论
你第四条写的什么python/lua + 一个合适的jit性能就足以保证了……这种玩笑还是别开了，我不知道那些语言写出个cry3画质的程序帧数会是什么样子。java开发的最成功的客户端游戏MC的执行效率足以证明。游戏引擎只有在脚本部分才会用到那些语言，lua就是那么被wow带火的。但wow的主题部分会用lua去写吗？C++还不需要虚拟机，依赖库，你又想说delphi也不要……当然delphi也不错，原来的第三方控件也很多，但现在用的人也不多吧，被宝蓝卖了后都不知道怎么样了，而且似乎还是走向了.net路线。果然VCL和MFC都老了。
这是一个快速迭代开发的时代，C++太重量级了，开发速度也很慢。使用快速的混合开发不是一种很好的方式么？当然我一开始就说这只是我个人推荐和使用的方式，大家是不是也需要就看个人的。
而且我说的层次和您用的方式不一样。C编译器一般人也可以维护起来，C++就不见得了（一些大厂商到现在还没有完全兼容C++03,11也只是有一部分支持）可以制定化制造自己CPU的公司也越来越多，为了获得更好的效能，现在都是Soc-CPU+GPU+VPU+FPGA加速。那问题就来了大厂商不会去帮你小厂商做支持的，而且小CPU厂商也没办法维护C++编译器。那最后还是要回到放弃FPGA的方式--没人开发编译器。如果使用C就可以有效的解决这个问题。一两个人维护c交叉编译器不是难事。
不要误解我，我没有说其他语言比C++强，而是混合开发的优势大于C++。图形引擎需要性能这个没的说，用ASM+C来开发，可是逻辑部分其实没多少性能需求用Lua,python也足够了，比如lua这样的轻量级语言，维护个Jit不是难事一个人也足够用了。芯片厂商专门划出一两个人来维护自己芯片加速指令和jit也是完全可以做到的。
请问这种方式不是更适合未来的开发模式么？当然了界面库之类的是需要完全重新开发，但是这也是大势所趋。而且我个人也在这方面开始自己的工作了，现在已经完成了windows，linux的一部分跨平台界面库（图形自绘的不是利用已有界面库）保证每个平台都得到相同的界面结果，asm+c写的底层速度有保证。即使未来要移植到嵌入式下也是换个交叉编译器重新编译的事情。
===================================================
会开源么？还是要收费？十分期待啊，希望早日用到！
另：现在用什么开发Windows（xp/2003/win7）桌面应用比较好？delphi、VB、还是C#?感觉被收购后的delphi有点像.net了，VB性能有点差，C#需要带.net framework，想来想去只能用VC++了
其实对于开源我相对保守，我觉得在中国别玩开源-就算开源也商业开源，老外玩得起是人家收入福利都够高，自己都还吃不饱就别装大方了。之所以中国程序员待遇低差说白了就是用开源的太多了。
Delphi XE+是原生开发根本不需要其他的DLL之类的就是体积有点大。2M左右，压缩一下也可以很小。你试过delphi的开发环境就知道了远比vs要强大的多。2010后delphi开始支持泛型,RTTI等特性(基本都没用过)
GO语言不适合开发桌面程序，首先开发桌面程序需要有界面库，IDE，调试器等多种配合才可以，WebKit您觉得效率够不？用户不关心你用什么开发，他们要更稳定，更快，更强大。而且webkit体积太大了吧？而且性能很差。你要是开发个游戏呢？
码奴的思维是怎么给自己省事，程序员的思维是怎么给用户省事。
技术难度高还能提高产品竞争力呢。不要站在代码角度而是用户角度去思考问题和选择技术。
引用来自“ichenshy”的评论
引用来自“七液”的评论
引用来自“ichenshy”的评论
引用来自“七液”的评论
引用来自“MatrixC”的评论
你第四条写的什么python/lua + 一个合适的jit性能就足以保证了……这种玩笑还是别开了，我不知道那些语言写出个cry3画质的程序帧数会是什么样子。java开发的最成功的客户端游戏MC的执行效率足以证明。游戏引擎只有在脚本部分才会用到那些语言，lua就是那么被wow带火的。但wow的主题部分会用lua去写吗？C++还不需要虚拟机，依赖库，你又想说delphi也不要……当然delphi也不错，原来的第三方控件也很多，但现在用的人也不多吧，被宝蓝卖了后都不知道怎么样了，而且似乎还是走向了.net路线。果然VCL和MFC都老了。
这是一个快速迭代开发的时代，C++太重量级了，开发速度也很慢。使用快速的混合开发不是一种很好的方式么？当然我一开始就说这只是我个人推荐和使用的方式，大家是不是也需要就看个人的。
而且我说的层次和您用的方式不一样。C编译器一般人也可以维护起来，C++就不见得了（一些大厂商到现在还没有完全兼容C++03,11也只是有一部分支持）可以制定化制造自己CPU的公司也越来越多，为了获得更好的效能，现在都是Soc-CPU+GPU+VPU+FPGA加速。那问题就来了大厂商不会去帮你小厂商做支持的，而且小CPU厂商也没办法维护C++编译器。那最后还是要回到放弃FPGA的方式--没人开发编译器。如果使用C就可以有效的解决这个问题。一两个人维护c交叉编译器不是难事。
不要误解我，我没有说其他语言比C++强，而是混合开发的优势大于C++。图形引擎需要性能这个没的说，用ASM+C来开发，可是逻辑部分其实没多少性能需求用Lua,python也足够了，比如lua这样的轻量级语言，维护个Jit不是难事一个人也足够用了。芯片厂商专门划出一两个人来维护自己芯片加速指令和jit也是完全可以做到的。
请问这种方式不是更适合未来的开发模式么？当然了界面库之类的是需要完全重新开发，但是这也是大势所趋。而且我个人也在这方面开始自己的工作了，现在已经完成了windows，linux的一部分跨平台界面库（图形自绘的不是利用已有界面库）保证每个平台都得到相同的界面结果，asm+c写的底层速度有保证。即使未来要移植到嵌入式下也是换个交叉编译器重新编译的事情。
===================================================
会开源么？还是要收费？十分期待啊，希望早日用到！
另：现在用什么开发Windows（xp/2003/win7）桌面应用比较好？delphi、VB、还是C#?感觉被收购后的delphi有点像.net了，VB性能有点差，C#需要带.net framework，想来想去只能用VC++了
其实对于开源我相对保守，我觉得在中国别玩开源-就算开源也商业开源，老外玩得起是人家收入福利都够高，自己都还吃不饱就别装大方了。之所以中国程序员待遇低差说白了就是用开源的太多了。
未来的发展绝对不可能是windows统一天下，如果linux和osx上的程序也和windows一样多的话。谁还会在windows上玩？病毒这么多（其实是客观原因造成的）以后平板，桌面，工作站都需要UI部分。
不是所有人都需要去维护一个引擎，否则游戏公司干什么都买引擎而不去自己开发，就是开发成本太高，买一个比较容易，而且开发周期也很短，赚钱快。看过游戏引擎代码就知道了里面不少代码都是asm优化的。OpenGL，DirectX只是提供了非常简单的图形操作接口，而不会帮你优化各种图形算法。所以开发通用跨平台的界面库我觉得至少我需要-DirectUI这样的。
你有钱的话，你会买apple的本本么？如果apple也可以dota，也可以视频，看片，play各种游戏的话。有钱人谁还用windows？
最后操作系统就会发展成：
用windows的都是屌丝
用OSX的都是有钱人
用linux的都是geek
程序员就要写出凌驾于操作系统和硬件上的软件，为什么总是要给微软打工呢？不要总是想着给自己省事，要想着给用户省事，用户需要什么。而不是总是想着自己开发简单，简单的东西别人都能做。你做出来也体现不出价值，要能做别人不能做的。
另外delphi xe4写的程序可以在iOS,OSX,Windows上执行。据说还要加入ARM支持，这样的话Android和iOS原生开发都可以进行了。至于您说的win7-delphi是最早支持win8开发的。可以下载个lite版本尝试一下。
引用来自“七液”的评论
引用来自“ichenshy”的评论
引用来自“七液”的评论
引用来自“MatrixC”的评论
你第四条写的什么python/lua + 一个合适的jit性能就足以保证了……这种玩笑还是别开了，我不知道那些语言写出个cry3画质的程序帧数会是什么样子。java开发的最成功的客户端游戏MC的执行效率足以证明。游戏引擎只有在脚本部分才会用到那些语言，lua就是那么被wow带火的。但wow的主题部分会用lua去写吗？C++还不需要虚拟机，依赖库，你又想说delphi也不要……当然delphi也不错，原来的第三方控件也很多，但现在用的人也不多吧，被宝蓝卖了后都不知道怎么样了，而且似乎还是走向了.net路线。果然VCL和MFC都老了。
这是一个快速迭代开发的时代，C++太重量级了，开发速度也很慢。使用快速的混合开发不是一种很好的方式么？当然我一开始就说这只是我个人推荐和使用的方式，大家是不是也需要就看个人的。
而且我说的层次和您用的方式不一样。C编译器一般人也可以维护起来，C++就不见得了（一些大厂商到现在还没有完全兼容C++03,11也只是有一部分支持）可以制定化制造自己CPU的公司也越来越多，为了获得更好的效能，现在都是Soc-CPU+GPU+VPU+FPGA加速。那问题就来了大厂商不会去帮你小厂商做支持的，而且小CPU厂商也没办法维护C++编译器。那最后还是要回到放弃FPGA的方式--没人开发编译器。如果使用C就可以有效的解决这个问题。一两个人维护c交叉编译器不是难事。
不要误解我，我没有说其他语言比C++强，而是混合开发的优势大于C++。图形引擎需要性能这个没的说，用ASM+C来开发，可是逻辑部分其实没多少性能需求用Lua,python也足够了，比如lua这样的轻量级语言，维护个Jit不是难事一个人也足够用了。芯片厂商专门划出一两个人来维护自己芯片加速指令和jit也是完全可以做到的。
请问这种方式不是更适合未来的开发模式么？当然了界面库之类的是需要完全重新开发，但是这也是大势所趋。而且我个人也在这方面开始自己的工作了，现在已经完成了windows，linux的一部分跨平台界面库（图形自绘的不是利用已有界面库）保证每个平台都得到相同的界面结果，asm+c写的底层速度有保证。即使未来要移植到嵌入式下也是换个交叉编译器重新编译的事情。
===================================================
会开源么？还是要收费？十分期待啊，希望早日用到！
另：现在用什么开发Windows（xp/2003/win7）桌面应用比较好？delphi、VB、还是C#?感觉被收购后的delphi有点像.net了，VB性能有点差，C#需要带.net framework，想来想去只能用VC++了
其实对于开源我相对保守，我觉得在中国别玩开源-就算开源也商业开源，老外玩得起是人家收入福利都够高，自己都还吃不饱就别装大方了。之所以中国程序员待遇低差说白了就是用开源的太多了。
引用来自“ichenshy”的评论
引用来自“七液”的评论
引用来自“MatrixC”的评论
你第四条写的什么python/lua + 一个合适的jit性能就足以保证了……这种玩笑还是别开了，我不知道那些语言写出个cry3画质的程序帧数会是什么样子。java开发的最成功的客户端游戏MC的执行效率足以证明。游戏引擎只有在脚本部分才会用到那些语言，lua就是那么被wow带火的。但wow的主题部分会用lua去写吗？C++还不需要虚拟机，依赖库，你又想说delphi也不要……当然delphi也不错，原来的第三方控件也很多，但现在用的人也不多吧，被宝蓝卖了后都不知道怎么样了，而且似乎还是走向了.net路线。果然VCL和MFC都老了。
这是一个快速迭代开发的时代，C++太重量级了，开发速度也很慢。使用快速的混合开发不是一种很好的方式么？当然我一开始就说这只是我个人推荐和使用的方式，大家是不是也需要就看个人的。
而且我说的层次和您用的方式不一样。C编译器一般人也可以维护起来，C++就不见得了（一些大厂商到现在还没有完全兼容C++03,11也只是有一部分支持）可以制定化制造自己CPU的公司也越来越多，为了获得更好的效能，现在都是Soc-CPU+GPU+VPU+FPGA加速。那问题就来了大厂商不会去帮你小厂商做支持的，而且小CPU厂商也没办法维护C++编译器。那最后还是要回到放弃FPGA的方式--没人开发编译器。如果使用C就可以有效的解决这个问题。一两个人维护c交叉编译器不是难事。
不要误解我，我没有说其他语言比C++强，而是混合开发的优势大于C++。图形引擎需要性能这个没的说，用ASM+C来开发，可是逻辑部分其实没多少性能需求用Lua,python也足够了，比如lua这样的轻量级语言，维护个Jit不是难事一个人也足够用了。芯片厂商专门划出一两个人来维护自己芯片加速指令和jit也是完全可以做到的。
请问这种方式不是更适合未来的开发模式么？当然了界面库之类的是需要完全重新开发，但是这也是大势所趋。而且我个人也在这方面开始自己的工作了，现在已经完成了windows，linux的一部分跨平台界面库（图形自绘的不是利用已有界面库）保证每个平台都得到相同的界面结果，asm+c写的底层速度有保证。即使未来要移植到嵌入式下也是换个交叉编译器重新编译的事情。
===================================================
会开源么？还是要收费？十分期待啊，希望早日用到！
另：现在用什么开发Windows（xp/2003/win7）桌面应用比较好？delphi、VB、还是C#?感觉被收购后的delphi有点像.net了，VB性能有点差，C#需要带.net framework，想来想去只能用VC++了
其实对于开源我相对保守，我觉得在中国别玩开源-就算开源也商业开源，老外玩得起是人家收入福利都够高，自己都还吃不饱就别装大方了。之所以中国程序员待遇低差说白了就是用开源的太多了。