在未来我们还需要纯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也算进去)自然可以应用的上。而且游戏现在越来越偏向于脚本化，毕竟引擎不是每个人都需要去修改，大部分人只是学习如何使用就可以了，LuaPython+一个合适的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可是它不跨平台。而且许多特性也满足不了轻量级需求，但是它很优秀)
参考：http://my.oschina.net/sw23120/blog/119584
———————————————————————————–
好吧 开始评论，我觉得C++不难学，难学的是架构的思想,Framework以及平台特性。
第一C可以做到的 C++依然可以做到，现在开发的问题主要是架构的老化，不要认为Lua，Java之类的东东效率高，Lua，C#这种东西比较新，框架比较新，所以还有很强的效率，Java架构都开始老化了，甲骨文没有的支持并不给力，频频爆出漏洞。而C++基本上流行的框架都到了要革新的时候了，MFC近20年，ATL也很多年了 在小型开发上来讲这是一种危害，效率低下，一个框架也都是向着复杂发展。只能是功能越来越多越来越复杂。这就是C++的主流困惑。
不过话有讲回来，当你代码量达到一定程度，并且又要高效，那么还是用C++，现在的LLVM/Clang全部用C++代码实现，GCC已经可以用g++（C++方式）编译，大型的项目要通过模块化简化开发难度，包括Java的编译器都是用C++实现，高超的C++项目是类和模版并用的。并且大量的虚拟机代码是危害效率的。
———————————————————————————–
C++不难学是您认为的，会的人当然觉得不难，我也觉得C++不难但是我不觉得C++是必须需要用到的，您认为您需要C++的时候其实您需要的也许是Python或者Delphi之类的。一个合格的C++程序员的确需要3-5年才能修炼成功这个已经是普遍观念了，而且性价比很低。
C可以用在单片机一些内存极小的嵌入式平台上，VxWorks等平台，这些都是C++做不到的。所以不要再说C可以做到的C++也可以做到。就这点C++就做不到。当然你可以完全写C Style的C++，可是那样的C++还有什么意义么？
C++是一个贪大求全的产物，当时OO刚兴起，什么都像往上上，纵观历史发展这种问题不是没有，古代士兵都上重甲，重装。后来随着战术的发展越来越发现速度远比防御要重要的多。C++什么都要上，C能做的他要能做，动态语言能做的他也要能做。现在完全就是为了全面而全面的扩展自己的性能了，C++11一看几乎涵盖了操作系统要做的东西了，就差垃圾回收+智能指针或者模板就可以称自己为动态语言了。一个如此复杂的语言学习成本又太高，STL和Boost其实也日渐老化，当然Boost我几乎没仔细学过，但是光看着这种重量级的架构我就觉得，这东西绝对不是我要的。
如果开发你用了100%的精力，那出错和调试您需要多大的精力？
Lua可以做到接近于C++的速度，设计结构老化是需要历史来证明的，用的人多了自然缺点慢慢显现出来，C++也是这样，早期大家认为OO可以抽象万物，但是他却忘记明日是不可预料的，你猜不出明天有什么需求，如何能预留出接口呢？效率低下可以改进。但是C++不是谁都能维护的太大的体积和各种成本后C++绝对不是很好的选择。
C++的确是模板+类混用的，可是由于这样的结果带来了程序的复杂性，linux代码很简单，随便一个c程序员都可以抄一段来用。可是我看过的C++工程那种复杂度实在不是一般人能看得懂，说句不好听的给你代码你都未必知道写的是什么，许多研究生到处兜售代码，可是没什么人买的原因也就是如此，看不懂实在是看不懂。
开发动态语言，需要性能和底层上C或者汇编来写。一切都调试ok了，实在不行还可以把动态语言直接输出成c语言。总体开发周期肯定小于C++，性能也绝对和C++相当甚至更强。虚拟机技术也在进步，虽然现在无法完全达到，但是不是做不到比如dotNET就做的非常好.
另外我说的小型处理器厂商的方案如何处理？维护gcc这样的工程需要一个非常大的团队。而一个c编译器只需要很小的团队，而且c语法由于简单，所以代码逻辑优化等等都比C++容易得多的多。这种优势必须看到，而且要知道以中国为例，编译器领域的人才其实凤毛麟角。要集结5-10个人的C++团队自然不如只需要1-2人的c团队要性价比更高~
当然个人认为的，大牛可以有其他更好的解决方法洗耳恭听。
———————————————————————————–
至于萝卜白菜各有所爱，比如我，倾向于研究操作系统，开发框架之类的底层，习惯认为C++好，而你的注重点不同，喜欢C，Python等，语言并没有什么优劣之分，只是适合干什么不适合干什么，根据你的定位去选择语言，在获取一些语言特色的同时肯定有所失，有得有失才是正常，还有评价一个语言尽量的客观一些。这样是有好处的。专注技术而不是专注分歧。
———————————————————————————–
操作系统几乎没有用C++开发的，请问您怎么用C++开发操作系统的？windows，linux，bsd，嵌入式操作系统，实时就更不用说了，几乎全部是c+asm开发的，您这句倾向于研究操作系统根据何在呢？
我一直都是用c+asm，delphi写代码的。这个就是让我感觉到迷茫的地方，C++的优势究竟在哪里，我用了两三年的C++，最后我还是决定退回到c+asm,C++的优势逐渐的被自身复杂和高昂的成本抵消了。
个人本身是做操作系统核心层的东西，包括安全，逆向，网络底层等研究的。而且越是这种底层越看不见C++，至于开发框架~C++也无法带来快速开发的效果，反而调试和移植成本会增加。这也是让我一直很头疼的事情。
至少我个人找不到使用C++的必要性了。当然了萝卜青菜各有所爱。
随着go等新型编译语言的诞生，人们更多的是需要轻量级而不是C++这样的庞然大物。而且都有替代方案，动态语言的特性更容易管理代码。C++还真的需要么？只是自己的个人想法，提出一种抛开C++的开发方案。当然只是个人的想法。多谢您的指点。
HaikuOS 引导都是C++，我对你的看法表示遗憾
———————————————————————————–
楼主的说法是现在C++没什么用武之地？但为什么我觉得现在大部分的桌面程序还是C++开发的？至少现在的java,python,ruby还是多用在服务端的开发吧，这些语言开发的桌面程序除了Eclipse之类的开发工具和比特彗星，openoffice，其他的恐怕并不多吧，就算你能列举出来几十个，能和C++的量比吗。QT,wxWidget之类的gui库本身就是用C++开发的，这不足以证明C++在这方面的优势吗。游戏开发就更不用说了，不管是开源还是闭源引擎，90%以上都是C++开发。约翰 卡马克刚开始也是用C来写的ID TECH引擎，到DOOM3的时候不也转C++了？别用自己的主管判断去否定产品，STL和BOOST的开发人员我觉得至少比你高明吧，他们难道闲着没事做这些复杂的工作打发时间？该死的东西总归会死，比如什么visual foxpro之类的，你说C++没用？困怕还早了点，而且这种话题难免引口水。就算是Linus都被人喷的飞去，何况你呢。
———————————————————————————–
你第四条写的什么python/lua + 一个合适的jit性能就足以保证了……这种玩笑还是别开了，我不知道那些语言写出个cry3画质的程序帧数会是什么样子。java开发的最成功的客户端游戏MC的执行效率足以证明。游戏引擎只有在脚本部分才会用到那些语言，lua就是那么被wow带火的。但wow的主题部分会用lua去写吗？C++还不需要虚拟机，依赖库，你又想说delphi也不要……当然delphi也不错，原来的第三方控件也很多，但现在用的人也不多吧，被宝蓝卖了后都不知道怎么样了，而且似乎还是走向了.net路线。果然VCL和MFC都老了。
———————————————————————————–
我可没觉得STL，Boost比个人写高明多少（你可以说重复造轮子，我来告诉你，内存占用太大，通用型根本不顶用给小菜用用可以，实际工作中用到的算法都要分支，动态规划重新设计的，所以STL，Boost根本没用。这就是CPU和FPGA的区别，真的高精度算法只能自己写，你没遇到只能说您做的工作实在是。。），DOOM3的代码是没办法，只能这么改（由于id被收购，而且大部分的引擎使用者都是C++er卡马克不得不妥协，难道你让那些C++程序员放弃C++都用c？）-仔细看过代码你就知道了。那叫C++？别因为看到几个class就认为他用C++其实很C style，另外C的占有率远比C++高得多。再来说说您所谓的C++优势吧，C++优势其实只有一条执行速度够快（另外一个很小的优势原生代码好加密）。要说OO和开发效率什么的真的不如动态语言来的快节奏。动态语言由于更好的动态特性可以提供更加强大的OO特性，这点C++是根本赶不上的（C++的各种特性实在是不好支持，由于是编译型语言所以C++编译器越来越臃肿，编译速度越来越慢）现在不少人还在用C++的原因其实是因为他们已经再用C++了。这就好比许多人就是习惯用XP，突然换成Win8觉得还不如XP呢，又换回去了。其实懒是最主要的原因。python，ruby，java不是不能开发客户端（大部分客户端不需要多高的性能需求，即使需要也完全可以用C来写）其实还是说那句话，没有人肯为这些语言的桌面化作出努力。如果完全抛开执行效率来说的话。您觉得哪种语言更适合使用呢？
linus被喷的原因是语气和态度，另外我不觉得C++有什么好的。不合格的C++程序员只会让代码更糟糕这个的确是真的（C++提供的特性太多，以至于许多小菜一上来什么特性都往里面用，而且stl，boost编译，调试很复杂，估计他走了也么人搞得懂这段代码写什么）linux内核需要的是一种是个人都能看得懂一目了然的代码。越简单的代码越容易维护。当然c也不是无懈可击（包管理太烂了。C++的namespace就很好，可是和python，ruby比又弱了许多）放弃C++是必然的，因为有更多新的语言诞生，更适合多人协作开发，包管理，模块化设计等等。另外stl，boost的算法一般人写写也要不了多久，他们没事搞这么复杂的东西其实就是闲着没事做了，比如loki就是为了证明自己能做到而搞的东西。未来多种语言维护的工程肯定越来越多。单一需要C++的不是很多了。即使是游戏C+lua或者Python也是可以搞定的。逻辑部分不需要太多的性能计算。
———————————————————————————–
大部分工程不需要很高的性能，比如界面库用C+asm来开发足以保证速度了，我说还有必要使用C++么不是说不用asm+c，即使是cry3内部也是嵌入了大量的asm来优化速度。你说的东西总是那么单一和绝对的东西，我又说完全使用一种语言开发么？不用c就用java？我从一开始说的就是混合开发没说使用单一语言开发。另外不懂delphi别说delphi，delphi被易博龙收购以后，出了Xe系列，现在XE3.5已经可以直接开发iOS程序了（原生直接编译出来，不需要freepascal了）而且VCL早就没人关注了，界面库也换成了FireMonkey，底层是DirectX+OpenGL实现的动态自绘窗口，也是为了跨平台设计的，当然由于高手走了不少体积实在是太大了（用了LLVM，没办法，不过现在还有多少人在乎多1m还是少1m的体积呢）XE4是可以直接开发Android和iOS程序的。.NET的话delphi早不玩了，VCL虽说比MFC先进，但是delphi现在也不是主力玩这个了。易博龙完全把它往跨平台方面打造了。可以搜索一下FireMonkey。
这是一个快速迭代开发的时代，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写的底层速度有保证。即使未来要移植到嵌入式下也是换个交叉编译器重新编译的事情。
———————————————————————————–
Delphi从VCL，CLX开始都是开源的，firemonkey现在也是开源的。直接就可以看到源代码。你可以直接修改之类的，VC不是RAD开发工具，只适合开发一些对性能需求很大的，而不是和做一些快速迭代开发。C#主要目标是Java，其实你仔细看就可以发现完全就是一个类Delphi的C系列语言。
主要也是面向企业级的，Delphi从诞生就是VBKiller不是给Delphi说好话，目前易博龙的确是做的比当初Borland要好的多。
随着Linux和OSX的崛起，Windows的市场不会再像以前这么大了。
话说回来了都选择CC++还把自己捆绑在Windows上不是有点说不过去么？之所以现在不少人还在用windows还是那句话。windows应用软件很成熟，Linux，OSX上开发根本都不需要什么创新，能把windows上比较经典的东西移植过去就是巨大的成功了。
phone,pad毕竟只是娱乐性产品，最终还是要回归原生开发上，JIT性能不是想象的这么好，而且更好点。用户才不关心你用什么开发，开发多久，人家想要的除了是更好用，还有速度更快，更省电。这正是原生开发的优势所在。当然对于C++我没什么想说的。C++程序员大部分都太烂了，过分迷信于设计模式和OO抽象机制。
程序=数据结构+算法。而不是什么抽象模型，谁也无法保证你今天写的结构还能满足明天的开发需要。
而且ASM+C有更好的优化和移植性。上层使用C++或者Lua或者Python来封装即可。业务逻辑经常需要修改，选择更具便捷性的语言才是正路，而C++不是什么好的设计语言。对于OO的诠释不完善而且开发成本很高，调试成本就更高了。
———————————————————————————–
不好意思我误解您的意思了。我是想做成Pelles’c这样的开发工具（而且自己构造一个交叉编译器和开发工具）而不是想单纯的要到OSX或者linux下重新编译。ASM+C我觉得足矣。上层配合Lua或者Python来调用也可以。实际优化上C++不占优势。而且64位下大部分编译器也都很不靠谱。VC++都无法内嵌asm，masm64居然连invoke和sdk包也没有。一切都要靠自己来实现呀。打算做完一个基础界面库的时候开源。高速界面库以后再说。目前基础界面库可以跑在Linux-GTK，Windows上了OSX目前在考虑是采用x11还是用Quartz。(x11其实很难用-快三十年了,所谓的经典设计说白了就是传统设计很难用)未来计划中其中一个很重要的环节。
其实对于开源我相对保守，我觉得在中国别玩开源-就算开源也商业开源，老外玩得起是人家收入福利都够高，自己都还吃不饱就别装大方了。之所以中国程序员待遇低差说白了就是用开源的太多了。
———————————————————————————–
ASM+C主要是用来做底层的，文章上已经说的很清楚了，比如说许多编译器暂时还没有聪明到可以把一些算法采用SIMD指令进行优化，所以ASM有些底层还是很有意义的，比如游戏和图形引擎中大量的使用内嵌汇编，包括操作系统的引导部分ASM都有需要必要存在，C主要用来组织和编写数据结构部分的代码。ASM只是为了弥补C的不足。当然你也可以用C写，可是作为一个游戏引擎程序员不会asm优化实在说不过去。内核程序员不会asm也说不过去。
未来的发展绝对不可能是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版本尝试一下。
———————————————————————————–
linux桌面现在也开始兴起了，许多游戏公司比如暴雪和valve都已经开始linux上的游戏开发了。开放一下思路。如果windows上的软件linux上都有。UI一样很简单漂亮谁愿意去买个windows？ubuntu就不是给服务器准备的。而且也都带桌面环境。另外说句不好听的。同样的软件linux或者OSX支持的话价格就比windows版本价格高出好多。而且OSX的反盗版和linux下的破解技术目前还非常落后（linux下源码调试都很痛苦，更别说在还没有什么好的二进制调试器的情况下玩破解了,Windows下有ollydbg,ida,windbg等等）
Delphi XE+是原生开发根本不需要其他的DLL之类的就是体积有点大。2M左右，压缩一下也可以很小。你试过delphi的开发环境就知道了远比vs要强大的多。2010后delphi开始支持泛型,RTTI等特性(基本都没用过)
GO语言不适合开发桌面程序，首先开发桌面程序需要有界面库，IDE，调试器等多种配合才可以，WebKit您觉得效率够不？用户不关心你用什么开发，他们要更稳定，更快，更强大。而且webkit体积太大了吧？而且性能很差。你要是开发个游戏呢？
码奴的思维是怎么给自己省事，程序员的思维是怎么给用户省事。
技术难度高还能提高产品竞争力呢。不要站在代码角度而是用户角度去思考问题和选择技术。
———————————————————————————–
语言争论真的是很多很多，但可以归根结底，是由于人之3~5年所学，不希望别人轻易否定过时或者不行，这不就等于在否定这个人么？
其实，C++能活到现在还前三（至少也是有科学依据的，对吧），一是历史遗留，二是确实有过人之处，正所谓，可恨之人必有可敬之处。
现在C++的问题，不在于其庞大，因为你尽可以选择自己喜欢的部分，而不需要求全。C++的问题还在于教学上，现存的C++er几乎都是从C学过来的吧，这样说来，使用C++的方式还是C的方式，C++支持多范式，从前面的讨论就可以看出来，class+template，是的！这才是基于对象而非面向对象的方式之一。
C++语法是比其他语言多，这也正是他的优势之一，C++可以让我们可以玩，其他语言能玩吗？虽然这句话很偏激，老板也不会喜欢！
语言是配料，不是工具！配料决定了设计方式，所以，语言会决定设计！从而影响更多后续。这也就解释了为什么很多人觉得C++的开发效率和可维护性很差–那是因为你的思维方式不同啊！
好吧，C++并不适合OO，这是OO的局限和C++的局限共同造成的，C++发展到今天，并不是庞大了，而是越来越合理，不过C++走在一条很荆棘的路上，既要能实现合理的抽象，满足变化，也还要高效的实现效率（设计效率、编译效率、运行效率），这，真惨！不过，生命在于折腾，不是吗？