C++的反思[转]

  1. 原文: http://www.skywind.me/blog/archives/1398?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io 

    最近两年 C++又有不少人出来追捧,而且追捧者充满了各类优越感,彷佛不写 C++你就一生是低端程序员了,面对这种现象,要不要出来适时的黑一下 C++呢?呵呵呵。javascript

    我们要有点娱乐精神,关于 C++的笑话数都数不清:php

    笑话:C++是一门不吉祥的语言,听说波音公司以前用ADA为飞机硬件编程,一直用的好好的,后来招聘了一伙大学生,学生们说我靠还在用这么落后的语言,而后换成C++重构后飞机就坠毁了。html

    笑话:什么是C++程序员呢?就是原本10行写得完的程序,他非要用30行来完成,并自称“封装”,但往往到第二个项目的时候却将80%打破重写,并美其名曰 “重构”。前端

    笑话:C容易擦枪走火打到本身的脚,用C++虽然不容易,但一旦走火,就会把你整条腿给炸飞了。java

    笑话:同时学习两年 Java的程序员在一块儿讨论的是面向对象和设计模式,而同时学习两年 C++的程序员,在一块儿讨论的是 template和各类语言规范到底怎么回事情。python

    笑话:教别人学 C++的人都挣大钱了,而不少真正用 C++的人,都死的很惨。mysql

    笑话:C++有太多地方可让一我的表现本身“很聪明”,因此使用C++越久的人,约以为本身“很聪明”结果步入陷阱都不知道,掉坑里了还以为估计是本身没学好 C++。android

    笑话:好多写了十多年 C++程序的人,至今说不清楚 C++到底有多少规范,至今仍然时不时的落入某些坑中。ios

    笑话:不少认为 C++方便跨平台的人,实际编写跨平台代码时,都会发现本身难找到两个支持相同标准的 C++编译器。 
    —————nginx

    Q:那 C++为何还能看到那么多粉丝呢? 
    A:实际上是由于 Windows,由于 Windows的兴起带动了 C++,C++原本就是一门只适合开发 GUI的语言。

    Q:为什么 C++只适合开发 GUI呢? 
    A:你看 Unix下没有 GUI,为啥清一色的 C呀?全部的系统级问题都能在 C里找到成熟的解决方案,应用级问题都能用其余高级语言很好地解决,哪里有 C++什么事情呀?

    Q:你强词夺理,Unix下也有 C++的项目呀。 
    A:有,没错,你任然能够用任何语言编写任何糟糕的代码。

    Q:别瞎扯了,你都在说些什么?连C++和 Windows 都扯到一块儿去了。 
    A:回想下当年的情景,一个大牛在教一群初学者如何编程。一边开发一边指着屏幕上说,你看,这是一个 Button,咱们能够用一个对象来描述它,那是一个 panel咱们也能够用一个对象来描述它,而且大家有没有发现,其实 Button和 Panel是有血缘关系的,大家看。。。这样就出来了。。。。下面的学生之前都是学着学校落后的教材,有些甚至还在用 turboc的 bgi库来画一些点和圆。哪里见过这么这么华丽的 Windows 界面呀。大牛说的话,象金科玉律同样的铭刻在本身幼小的心理。一边学着 Windows,一边发现,果真,他们都须要一个基类,果真,他们是兄弟关系,共同包含一些基本属性,能够放到基类去。他们越用越爽,潜意识里以为由于 C++这么顺利的帮他们解决那么多界面问题,那看来 C++能够帮他们解决一切问题了。因而开发完界面之后,他们继续开发,当他们碰到各类设计问题时,反而认为确定本身没有用好 C++。因而强迫本身用下去,而后就完蛋了。

    (点击 more展开)

     

    ————— 
    关于 C++的笑话我有一箩筐,各位 C++粉用不着对号入座。言归正传,为何要黑 C++呢?谈不上黑不黑,我从94年开始使用 C++(先前是 C 和 Pascal),一路看着 C++成长壮大,用 C++写过的代码,加起来应该超过 10MB了吧,C++的各类宝典我也都读过,一直到 2004年开始切回 C,主要缘由是发现不少无法用 C++思路继续解决下去的问题,或者说用 C++思路解决下去会很糟糕的问题。

    那时候(2004-2005)正是 C++满天飞的时候,言必称 C++,用必用模版,我跳出来讲大家醒醒吧,别过火了,这个世界并非都是抽象数据结构和算法就能够描述清楚的。因而不少人激动的跳出来讲:“你没领会到 C++精髓,你根本都不会用 C++”。我问他们:“语言是用来解决问题的,若是一个语言学了三四年都会常常掉沟里,算好语言么?若是编写十多年 C++的程序员都很难掌握得了,这算好语言么”。他们又说:“语言是死的,人是活的”。

    我记得当时一位国内 C++大牛,为了纠正个人 “错误观点”,给我看过他写的一套十分强大的库,我打开一看,倒吸了一口冷气,所有是 .h文件。我只能回他三个字:“你牛逼”。固然这是一个极端的例子,那家伙后来终于也开始把 .h里面的东西逐步挪到 .cpp里面了,这是好事。

    当时和云风在一家公司,2004年新人培训时,他给新人布置了一个实现内存分配器的做业,批改做业的时候,他常常边看边问人家,“不够C++呀,你能不能百分之百OOP?”,“1%的 C都不要留”。我当时在公司内部邮件列表里面发过关于 C++的问题,大部分人都表示:“你看没有C++咱们怎么写3D引擎呢?”。我跟他们讲:“John Carmack直到 Quake3都还在用着 ANSI C,后来由于不得不支持 D3D,改用 C++了。为啥 C不能写 3D引擎了?”。他们告诉我:“你看,Point,就是个对象,Matrix也是个对象,那么多 Vector的代数计算,用 C++的算术重载是多么美妙的事情,三维世界就是对象的世界。”。

    确实当时客户端 GUI的话,只有 C++,图形引擎也只有 C++,这两个正是C++最强的地方,因此我也没和他们争辩,强迫他们认可 C也能够很漂亮的写图形,并且C写的能够写的很优雅。我又不是闲着没事情,何须去质疑人家的核心价值观呢,呵呵。当年我正在接手一个 C++项目,代码超过 800KB,每次崩溃都须要花费很长时间去定位,项目中大量的先后依赖,改一个地方,先后要看好几处,一处遗漏,整个系统就傻逼了。我开始重构后,画了两个星期,将性能敏感的核心部分剥离出来用 C实现(代码量仅 200KB),而后导出 Python接口,用Python来完成剩下的部分,整个脚本层代码量只有 150KB。整个世界清爽了,整个 C++项目原来的工期为 2个程序员四个月,我一我的重构的时间加起来就 1.5个月,并且代码量比远来少了两倍还多,各类奇特的 BUG也一扫而尽。我看看左边的 800KB一团乱麻的 C++代码,再看看右边整洁的 300多 KB 纯 C + Python,琢磨着,这个项目干吗不一开始就这么作?

     

    跨语言接口

     

     

     

    现代项目开发,不但须要更高的性能,并且须要更强大的语言描述能力。而 C++正处在一个尴尬的地方,比底层,它不如 C可以精确的控制内存和硬件,各类隐式构造让你防不胜防;比描述能力,比快速业务开发和错误定位,它又赶不上 Python, Ruby, Lua等动态语言,处于东线和西线同时遭受挤压和蚕食的地步。

    很快,2006-2007年左右,其余项目组各类滥用 C++的问题开始显现出来:当时脚本化已经在工程实践中得到极大的成功,然而某些项目一方面又要追求 100%的 C++,另外一方面又须要对脚本导出接口,他们发现问题了,不知道该怎么把大量的 C++基础库和接口导给 Lua。

    C的接口有各类方便的方式导给脚本,然而整个项目由一群历来就不消于使用脚本的cpp大牛开发出来,当他们要吧cpp类导出接口给脚本时,他们设计了一套牛逼的系统,lua自动生成机器码,去调用c++的各类类,没错,就是c++版本的cffi或者ctypes。他为调用vc的类写了一套机器码生产,又为调用gcc的类写了一套代码生成。那位cpp大牛写完后四处炫耀他的成果,后来他离职了,项目上线一而再再而三的出现无可查证的问题,后来云风去支援那个项目组,这套盘根错节的c++项目,这套盘大的代码自生成系统深深的把他给恶心到了。后来众所周知云风开始反C++,倡导回归C了,不知道是否和这个项目有关系。

    因而发现个有趣的现象,但凡善于使用脚原本提升工程效率的人,基本都是C加动态语言解决大部分问题(除了gui和图形),但凡认为c++统治宇宙的人不少都是历来没使用过脚本或者用了还不知道该怎样去用的人。

    凭借这样的方法,咱们的产品同竞争对手比拼时,一样一个功能,一样的人力配置,竞争对手用纯C++要开发三月,咱们一个月就弄出来了,一样的时间,对手只能试错一次,咱们能够试错三次。后来,据咱们招聘过来的同事说,竞争对手也开始逐步下降 C++的比例,增长 java的比例了,这是好事,你们都在进步嘛。

     

    ABI的尴尬

     

     

     

    ABI级别的 C++接口历来没有标准化过,以类为接口会引入不少隐藏问题,好比内存问题,一个类在一个库里面实例化的,若是再另一个库里面释放它们就有不少问题,由于两个动态库可能内存管理系统是不同的。你用这里的 allocator分配一块内存,又用那里的 allocator去释放,不出问题才怪。不少解决方法是加一个 Release 方法(好比 DX),告诉外面的人,用完的时候不要去 delete,而是要调用 Release。

    项目写大了各个模块隔离成动态库是很正常的,而各类第三方库和本身写的库为追求高性能引入特定的内存管理机制也是很正常的。不少人不注意该调用release的地方错写成delete就掉沟里去了。更有胜者跨 ABI定义了不少inline方法的类,结果各类隐式构造和析构其实在这个库里生成,那个库里被析构,乱成一团乱麻。C就清晰不少,构造你就调用fopen,析构你就fclose,没有任何歧义。其实C++的矛盾在于一方面认可做为系统级语言内存管理应该交给用户决定,一方面本身却又定义不少不受用户控制的内存操做行为。因此跨 ABI层的c++标准迟迟没法被定义出来,不是由于多态 abi复杂,而是由于语言逻辑出现了相互矛盾。为了弥补这个矛盾,C++引入了operator new,delete,这new/delete重载是一个补丁并没从逻辑上让语言变得完备,它的出现,进一步将使用者拖入bug的深渊。

    其实今天咱们回过头去看这个问题,能发现两个基本原则:跨abi的级别上引入不可控的内存机制从语言上是有问题的,只能要靠开发者约定各类灵巧的基类和约定开发规范来解决,这个问题在语言层是解决不了的;其次你既然定义了各类隐式构造和析构,就该像java或者动态语言同样完全接管内存,不容许用户再自定义任何内存管理方法,而不是一方面做为系统极语言要给用户控制的自由,一方面本身又要抢着和用户一块儿控制。

    所以对象层 ABI接口迟迟没法标准化。而纯 C的 ABI不但能够轻松的跨动态库还能轻松的和汇编及各种语言融合,不是由于C设计多好,而是C做为系统层语言没有去管它不应管的东西。当年讨论到这个话题时 C++大牛们又开始重复那几句金科玉律来反驳我:“语言只是招式,你把内功练好,就能作到无招胜有招,拿起草来均可以当剑使,C++虽然有不少坑,你把设计作好不那么用不就好了”。我说:原本应该在语言层解决好的事情,因为语言逻辑不完备,将大量问题抛给开发者去解决极大的增长了开发者的思惟负担,就像破屋上表浆糊同样。你金庸看多了吧,武术再高,当你拿到一把枪发现子弹不必定往前射,偶尔还会日后射时,请问你是该专心打敌人呢?仍是时刻要提防本身的子弹射向本身?

     

     

     

    系统层的挫败

     

     

     

    C++遭受挫败是进军嵌入式和操做系统这样靠近硬件层的东西。你们以为宇宙级别的编程语言,天然可以胜任一切任务,很快发现几个问题:

    • 没法分配内存:原来用 C能够彻底不依赖内存分配,代码写几千行一个 malloc没有都行。嵌入式下处理器加电后,跳到特定地址(好比起始地址0),第一条指令通常用汇编来写,固定在0地址,就是简单初始化一下栈,而后跳转到 C语言的 start函数去,试想此时内存分配机制都尚未创建,你定义了两个类,怎么构造呀?资源有限的微处理器上大部分时候就是使用一块静态内存进行操做。C++写起来写爽了,各类隐式构造一出现,就傻了。
    • 标准库依赖:在语言层面,C语言的全部特性均可以不用依赖任何库就运行,这为编写系统层和跨平台跨语言代码带来了很方便的特性。而C++就不行,我要构造呀,我要异常呀,你为啥不能给我强大的运行时呢?什么你还想用 stl?不看看那套库有多臃肿呀(内存占用,代码尺寸)。
    • 异常处理问题:底层开发须要严格的处理全部错误返回,这一行调用,下一行就判断错误。而异常是一种松散的错误处理方式,应用层这么写没问题,系统层这么写就很狼狈了。每行调用都try一下和 C的调用后if判断结果有什么区别?C++的构造函数是没有返回值的,若是构造内部出错,就必须逼迫你catch构造函数的异常,即使你catch住了,构造异常的时候固然会自动触发相关内部对象的析构,可是有不少并无析构的资源(好比系统资源,好比C接口的资源,他们都没有一个析构),整个过程是很难控制的,此时这个实例是一个半初始化实例,你该怎么处理它呢?因而有人把初始化代码移除构造函数,构造时只初始化一下变量,新增长一个带返回的init函数,这样的代码写的比C冗余不少。况且硬件中断发生时,在你不知道的状况下,同事调到一些第三方的库,你最外层没有把新的exception给 catch住,这个exception该往哪里抛呀?内存不够的时候你想抛出一个 OutOfMemoryException,但是内存已经不够了,此时彻底无能力构造这个异常又该怎么办呢?
    • 处理器兼容:C++的类依赖基地址+偏移地址的寻址方式,不少非 Intel系列的微处理器上只有简单的给定地址寻址,不支持这样一条语句实现BASE+OFFSET的寻址,不少C++代码编译出来须要更多的指令来运算地址,致使性能降低不少,得不偿失。
    • 隐式操做问题:C的特色是简单直接,每行语句你都能清楚的知道会被翻译成什么样子,系统会严格按照你的代码去执行。而用C++,好比 str1 = str2 + "Hello" + str3; 这样的语句,没几我的真的说得清楚究竟有多少次构造和拷贝,这样的写法编写底层代码是很不负责任的,底层须要更为精细和严格的控制,用C语言控制力更强

    固然,说道这里不少人又说,“C++原本就是 C的超集,特定的地方你彻底能够按照C的写法来作呀。没人强迫你构造类或者使用异常呀”,没错,按 Linus的说法:“想要用 C++写出系统级的优秀的可移植和高效的代码,最终仍是会限于使用 C自己提供的功能,而这些功能 C都已经完美提供了,因此系统层使用 C的意义就在于在语言层排除 C++的其余特性的干扰”。

    不少人都记得 Linus在 2007年由于有人问 Git为何不用 C++开发炮轰过一次C++。事实上2004年 C++如日中天的时候,有人问 Linux内核为什么不用 C++开发,他就炮轰过一次了:

    实际上,咱们在1992年就尝试过在Linux使用 C++了。很恶心,相信我,用C++写内核是一个 “BLOODY STUPID IDEA”。事实上,C++编译器不值得信任,1992年时它们更糟糕,而一些基本的事实从没改变过:

    – 整套 C++异常处理系统是 “fundamentally broken”。特别对于编写内核而言。 
    – 任何语言或编译器喜欢在你背后隐藏行为(如内存分配)对于开发内核并非一个好选择。 
    – 任然能够用 C来编写面向对象代码(好比文件系统),而不须要用 C++写出一坨屎来。

    总得来讲,对任何但愿用 C++来开发内核的人而言,他们都是在引入更多问题,没法象 C同样清晰的看到本身到底在写什么。

    C++粉丝们在C++最火热的时候试图将 C++引入系统层开发,可是历来没有成功过。因此无论是嵌入式,仍是操做系统,在靠近硬件底层的开发中,都是清一色的 C代码,彻底没有 C++的立锥之地。

     

     

     

    应用层的反思

     

     

     

    STL出来后,给人一种 C++能够方便开发应用层逻辑的错觉。因为不少语言层不严密的事情,让STL来以补丁的方式完成,因而不少觉得能够象写 java同样写 C++的初学者落入了一个个的坑中。好比 list.size(),在 Windows下vc的 stl是保存了 list的长度的,size()直接 O(1)返回该变量,而在gcc的 stl中,没有保存 list长度,size()将搜索全部节点,O(n)的速度返回。

    因为语言层不支持字符串,致使 std::string实现十分不统一,你拷贝构造一个字符串,有的实现是引用,才用 copy-on-write的方法引用。有的地方又是 new,有的实现又是用的内存池,有的实现线程安全,有的实现线程不安全,你彻底无法说出同一个语句后面到底作了些什么(见孟岩的《Linux之父话糙理不糙》)。

    再好比说我想使用 hash_map,为了跨平台(当你真正编写跨平台代码时,你很难决定目标编译器和他们的版本,想用也用不了 unordered_map),我很难指出一种惟一声明 hash_map的方法,为了保证在不一样的编译器下正常的使用 hash_map,你不得不写成这样:

    #ifdef __GNUC__ 
        #ifdef __DEPRECATED 
            #undef __DEPRECATED 
        #endif 
        #include <ext/hash_map> 
        namespace stdext { using namespace __gnu_cxx; } 
        namespace __gnu_cxx { 
            template<> struct hash< std::string > { 
                size_t operator()( const std::string& x ) const { 
                    return hash< const char* >()( x.c_str() ); 
                } 
            }; 
        } 
    #else 
        #ifndef _MSC_VER 
            #include <hash_map> 
        #elif (_MSC_VER < 1300) 
            #include <map> 
            #define IHAVE_NOT_HASH_MAP 
        #else 
            #include <hash_map> 
        #endif 
    #endif

    #ifdef __GNUC__ 
        using namespace __gnu_cxx; 
        typedef hash_map<uint32_t, XXXX*> HashXXXX; 
    #else 
        using namespace stdext; 
        typedef hash_map<uint32_t, XXXX*> HashXXXX; 
    #endif

    若是有更好的跨平台写法,麻烦告诉我一下,实在是看不下去了。一个基础容器都让人用的那么辛苦,使得不少 C++程序员整天都在思考各类规范,没时间真正思考下程序设计。

    因为语言层要兼容 C,又不愿象 C同样只作好系统层的工做,致使当 C++涉足应用层时,无法接管内存管理,无法支持语言层字符串,无法实现语言层基础容器。因此须要借助一些 stl之类的东西来提供便利,但 stl自己又是充满各类坑的。且不说内存占用大,程序体积大等问题,当编译速度就够呛了。因此为何 C++下面你们乐意重复造轮子,实现各类基本容器和字符串,致使几乎每一个不一样的 C++项目,都有本身特定的字符串实现。就是由于你们踩了坑了,才开始以为须要本身来控制这些细节。stl的出发点是好的,可是只能简单小程序里面随便用一下,真是大项目用,stl就容易把人带沟里了,因此不少大点的 C++项目都是本身实现一套相似 STL的东西,这难道不是违背了 stl设计的初衷了么?

    语言层的缺失,让你们为了知足业务开发的快速迭代的需求,创造了不少很基础的设计灵巧的基类,来提供相似垃圾回收,引用计数,copy-on-write,delegate,等数不胜数的功能。每一个项目都有一系列 BaseObject 之类的基础类,这样就引入一个误区,两年后你再来看你的代码,发现某个 BaseObject不知足需求了,或者你和另一个项目 merge代码时,须要合并一些根本属性。图形和GUI这些万年不变的模型还好,应用类开发变幻无穷,一旦这些设计灵巧的基类再也不适应项目发展时,每每面临着全面调整的代价。

    打开一个个 C++大牛们 blog,不少地方在教你 std::string的原理,须要注意的事项。map的限制,vector的原理,教你如何实现一个 string。这就叫 “心智负担”,分散你的注意力,这是其余语言里历来见不到的现象。战士不研究怎么上前线杀敌,每天在琢磨抢和炮的原理,整天在思考怎么用枪不会走火,用炮不会炸到本身,这战还怎么打?

    因此此后几年,愈来愈多的人开始反思前两年C++过热所带来的问题,好比高性能网络库 ZeroMQ做者 Martin Sustrik 的:《为何我但愿用C而不是C++来实现ZeroMQ》,好比云风的《云风的 BLOG: C 的回归》,好比引发热议的《Why C++ Is Not "Back"》。

     

    全面被代替

     

     

     

    2008年之后,行业竞争愈来愈激烈,正当你们一边苦恼如何提升开发效率,一边掉到C++的各类坑里的时候,愈来愈多的应用开发方案涌现出来,他们都能很好的代替 C++。各行各业的开发者逐步相见恨晚的发现了各类更加优秀的方案:须要底层控制追求性能的设计,你们退回到 C;而须要快速迭代的东西你们找到各类动态语言;介于性能和开发速度之间的,有java,知乎上好像不少黑java的,语言是有不足,可是比起C++好不少,没那么多坑,真正考虑面向对象,真正让人把心思放在设计上。因此再黑也不能挡住 java在 tiobe上和 C语言不是第一就是第二的事实,再黑也挡不住 java在云计算,分布式领域的卓越贡献。

    因此2005年之后,C++处在一个全面被代替的过程当中:

    image

    • 底层系统:进一步回归 C语言,更强的控制力,更精确的操做。
    • 网页开发:2006年左右,C++和 fastcgi就被一块儿赶出 web世界了。
    • 高性能服务:varnish, nginx, redis 等新的高性能网络服务器都是纯C开发的。
    • 分布式应用:2007年左右, C++被java和其余动态语言完全赶跑。
    • 游戏服务端:2008年后进一步进化为 C 和 脚本,彻底看不到胖C++服务端了。
    • 并行计算:2010年后,go, scala, erlang;而能方便同go接口的,是 C不是C++。
    • 游戏引擎:没错 C++和脚本,可是这年头愈来愈多的开源引擎下,引擎类需求愈来愈少。
    • 游戏逻辑:脚本
    • 多媒体:SDL纯C,ffmpeg是纯 C,webrtc的核心部分(DSP, codec)是纯C的。
    • 移动开发:早年C++还能够开发下塞班,如今基本被 java + objc + swift 赶跑了。
    • 桌面开发:Qt+Script, C#等都能作出漂亮的跨平台界面。且界面脚本化趋势,不须要C++了。
    • 网页前端:JavaScript, Html5, Flash
    • 操做系统:FreeBSD, Open Solaris, Linux, RTOS, Darwin(OS X 底层),都是纯 C
    • 虚拟技术:qemu / kvm (云计算的基石)纯 C,Xen 纯 C
    • 数据库:MySQL (核心纯C,外围工具 C++),SQLite 纯 C, PostgreSQL / BDB / unqlite 纯C
    • 编译器:C/C++并存,不过编译器用脚本写都不要紧,我还在某平台用 java写的 C/C++编译器
    • 大数据:kafka, hadoop, storm, spark 都使用 Java / Jvm 系列技术
    • 云存储:openstack swift python, hdfs java, 还有好多方案用 go

    能够看出,即使 C++的老本行,GUI和图形(确实也还存在一些短时间内 C++没法替代的领域,就像交易系统里还有 COBOL同样),这年头也面临的愈来愈多的挑战,好比新发布的 Rust (如何看待 Rust 的应用前景? – 知乎用户的回答)。能够发现,开发技术多元化,用最适合的技术开发最适合的应用是将来的趋势。而为这些不一样的技术编写高性能的可控的公共组件,并轻松的和其余语言接口,正是 C语言的强项。因此无论应用层语言变幻无穷,对系统级开发语言C的需求仍是那么的稳定,而这个过程当中,哪里还有 C++的影子呢?

     

    话题总结

     

     

    因此说将来的趋势是:C x 各类语言混搭 的趋势,从TIOBE上 C++的指数十年间下跌了三倍能够看出,将来还会涌现出更多技术来代替各个角落残存的C++方案,C++的使用状况还会进一步降低。因此题主问学习纯C是否有前途,我以为若是题主可以左手熟练的掌握 C语言,培养系统化的思惟习惯和精确控制内存和硬件的技巧;右手继续学习各类新兴的开发技术,可以应对各个细分领域的快速开发,碰到新问题时能双管齐下,那么将来工做上确定是能上一个大台阶的。至于C++ 嘛,有时间看看就行,逼不得已要维护别人代码的状况下写两行便可。

     

    故事分享

     

     

     

    古代用弓箭进行远距离攻击时,对射手要求较高,瞄准难度大,须要一直使劲保持准心。战斗中一个弓箭手开弓二十次就须要比较长的休息时间。弩的威力远胜于弓,秦弩的制造就如现代的自动步枪通常精密无二,它既能够延长射击,又能够精确瞄准。弩箭的发射速度更是弓箭的数倍,威力惊人。由于弩的操做很是简单,不须要射击技巧,平民很容易掌握它的使用方法。秦国靠着弩兵,在战争中取得了很多优点,被人称为 “虎狼之师”。

    日本投降时,天皇下罪己诏。不少士兵不肯意相信这时真的,找种种理由拒绝相信。有的士兵甚至觉得天皇的广播是敌人诱降的把戏,因而躲到丛林里继续成群结队的收集情报,袭击能够攻击的目标,等待上司来给他们下达新命令。直到好几年后看到周围的人都穿着平常的便装了,而来巡山的 “敌人” 也从士兵变为了巡逻队,他们都还以为这是敌人的假装。而同时,德国战败时,最后的党卫军一直战斗到 1957年才肯投降。

    —————————————– 
    不少人以为 java慢,C++快java 10倍以上已是上世纪的事情了,现代的 java 只比 C/C++慢 70%,C++连1倍都快不了 java。也不要以为动态语言慢,javascript只比C/C++慢 2.7倍。luajit只比 C++慢 5.8倍。在 jit技术发展的今天,C++在性能上离动态语言/java的差距愈来愈小,可易用性和生产效率上的差距,却和动态语言/java 比起来愈来愈大。

    image

    ————————— 
    最后,补充一张图: 
    image

     
    Categories:编程技术随笔Tags:C++
    Comments (58) Trackbacks (2) Leave a commentTrackback
     
    1. dictator
      June 18th, 2015 at 13:38 |  #1
      Reply |  Quote
       

      最后的图好赞

       
    2. June 19th, 2015 at 17:51 |  #2
      Reply |  Quote
       

      @dictator 
      哈哈,作了好长时间呀,这图片。

       
    3. kasicass
      July 2nd, 2015 at 13:09 |  #3
      Reply |  Quote
       

      :-) 赞

       
    4. gaover
      July 5th, 2015 at 20:41 |  #4
      Reply |  Quote
       

      游戏服务端:2008年后进一步进化为 C 和 脚本,彻底看不到胖C++服务端了。
      这个不许吧, 我看招聘中主要是c++和java,我以前只搞过c人家都是: 你没搞过c++???
      因此如今还在找。。。。

      最后的图不错。

       
    5. jssss
      July 11th, 2015 at 01:04 |  #5
      Reply |  Quote
       

      Very good! I am studying the Java and Python techniques now.

       
    6. July 20th, 2015 at 11:32 |  #6
      Reply |  Quote
       

      大部分赞同,除了性能比较那部分。

      我更看好go代替C++。

       
    7. July 20th, 2015 at 11:47 |  #7
      Reply |  Quote
       

      “战士不研究怎么上前线杀敌,每天在琢磨抢和炮的原理,整天在思考怎么用枪不会走火,用炮不会炸到本身,这战还怎么打?” 这句话太经典了。哈哈哈哈哈。

       
    8. LiLiLi
      July 20th, 2015 at 13:22 |  #8
      Reply |  Quote
       

      毫无养分的文章。。。

       
    9. LiLiLi
      July 20th, 2015 at 13:39 |  #9
      Reply |  Quote
       

      @LiLiLi 
      看了下楼主的博客,仍是很佩服的,不过这篇文章说C++狗屁不行仍是值得商榷的。

       
    10. august
      July 20th, 2015 at 15:55 |  #10
      Reply |  Quote
       

      这样黑c++好吗?

       
    11. shady
      July 20th, 2015 at 16:28 |  #11
      Reply |  Quote
       

      “大数据:kafka, hadoop, storm, spark 都使用 Java”
      — 虽然都是JVM系的,但Kafka和Spark是Scala写的,Storm是Clojure写的。

       
    12. July 20th, 2015 at 18:34 |  #12
      Reply |  Quote
       

      @shady 
      嗯,了解。

       
    13. July 20th, 2015 at 18:39 |  #13
      Reply |  Quote
       

      @august 
      有点娱乐精神嘛,再说我又不是去论坛的 C++ 板块发这样的文章拉仇恨,就在本身的博客上写写玩玩,何须认真呢?

       
    14. dzm
      July 21st, 2015 at 08:46 |  #14
      Reply |  Quote
       

      呵呵

       
    15. Binresist
      July 21st, 2015 at 14:56 |  #15
      Reply |  Quote
       

      感受像看了篇小说,由于我哪一种语言都不精,因此并无太大的感慨,但前一段时间写一个跨平台的小程序时,确实以为C++有点,纠结。

       
    16. 农民工
      July 21st, 2015 at 23:00 |  #16
      Reply |  Quote
       

      一开始的笑话仍是不错的,尤为是真正作过C++的人。对于喷子们(不管是否是C++的粉),很容易出现X点。

      另外我只是以为,不管C和C++,主要是可让人了解一些偏底层的东西,尤为是一上来只写了java、c#这些更高级别的语言的亲。这其实也是C,C++都有的优势。

      另外,C++确实被搞乱掉了。不过说句内心话,若是接触了比较不错框架的C++项目仍是不错的,至少有些不错的框架代码很是简洁,写代码的很溜。

      我是个写C++有点时间的,菜鸟一个。C++确实不是一个友好的语言,可是来学C++或者使用C++人也有一部分存在技能层次不齐。确实要写好C++,除了常规的要如何考虑如何设计一个业务抽象,或者框架。还要对C++一些乱七八糟的规则和“坑”有所了解。

      用好C++感受像怕珠穆朗玛,不是C++伟大,而是规范没作好。你对C++确实很了解,只不过我以为你可能过激了一点,理性对待。不错的框架和代码仍是有的,只不过少,语言分工和特性形成了。

       
    17. hank
      July 21st, 2015 at 23:06 |  #17
      Reply |  Quote
       

      luajit只比 C++慢 5.8 ?

      因此是 10000000 跟 58000000 在線人數的差異囉?

      c++ 用 100 台 server / luajit 要用 580 台?

      果真是 “速度不輸” c++ 啊

       
    18. Hell
      July 22nd, 2015 at 08:42 |  #18
      Reply |  Quote
       

      现代的 java 只比 C/C++慢 70%,C++连1倍都快不了 java。
      那为何大型游戏不用Java来写。

       
    19. July 22nd, 2015 at 10:35 |  #19
      Reply |  Quote
       

      @hank 
      你没有作过 server 吧,大部分 server,包括游戏和 WEB,是卡在I/O等待上,还有频繁的系统调用上。根本不是卡在逻辑的 CPU 计算上,即使有一些性能铭感的逻辑模块,用C写了导出给脚本便可,好比游戏的 AI,这样的模块并很少。

       
    20. July 22nd, 2015 at 10:37 |  #20
      Reply |  Quote
       

      @Hell 
      服务端:早年 java 没有 NIO,如今有了,确实有不少大型游戏的服务端用 java 来写的。
      客户端:java图形能力界面能力不强,客户端图形主要仍是C++,我上文也说了。不过如今脚本和objc等也不少了。

       
    21. July 22nd, 2015 at 11:41 |  #21
      Reply |  Quote
       

      C+动态语言确实感受不错

       
    22. hank
      July 22nd, 2015 at 19:04 |  #22
      Reply |  Quote
       

      @skywind 
      一直在寫 server …

      但現在講的是 luajit 跟 c++ 的速度~ 不是指 I/O 等待的問題啊~~ 不是嗎? 難道 5.8 倍指的是 IO 等待的時間嗎?

      并且試過 3000 玩家在同一個 “畫面” 上的 AStart 及 AOI 的壓力測試嗎? 不知道慢了 5.8 倍的 luajit 跑起來會如何….

       
    23. hank
      July 22nd, 2015 at 20:06 |  #23
      Reply |  Quote
       

      用中文寫不出莎士比亞是中文的錯嗎?
      用英文寫不出將進酒是英文的錯嗎?

      c++ 真的很差嗎? 有時候用的人能力夠不夠很重要.

      目前的工做有一部份是優化前人留下的代碼, 本来的寫法是直接在 IO 線程裡直接一把大鎖鎖住全部的用戶對象, 然後處理業務邏輯, 但要處理業務邏輯根本不须要鎖住全部的用戶對象, 有時只是某個用戶對象單獨的數據修改而已.

      我接手協助優化是加入了智能指針,將大鎖切割為個別的小鎖, 整體效能有提高了很多, 也間接的解決很多 bug.

      這個部份並不是要說 c++ 有多好用,只是要說好的語言也要有會用的人
      若是思想錯誤, 一樣一把大鎖鎖住全部的用戶對象, 然後處理業務邏輯, 就算用 c/java/luajit/..其余的鬼東西 寫, 寫出來就會比較好嗎?

      若是有神一樣的工具能够把豬一樣的設計師寫出來的鬼代碼變整天上掉下來的禮物,那我想也不须要所謂的資深程式設計師/主程, 直接叫美術人員寫程式就行了.

       
    24. RisingV
      July 24th, 2015 at 17:05 |  #24
      Reply |  Quote
       

      有些地方仍是太片面了。
      好比:
      try-catch-throw 不止是c++有,不少其余语言也有。相比与函数返回错误,仍是有一些进步的。
      返回值的方式,须要调用函数的处添加错误判断代码,即使没有错误。并且,错误的传递依赖于调用处显式返回给下一个调用者。整个调用栈每一层都要做判断和传递。try-catch-throw可以让异常在调用栈上跳跃传递,只让真的能处理异常的地方去处理异常。

       
    25. July 24th, 2015 at 18:28 |  #25
      Reply |  Quote
       

      @hank 
      AStar不是通常放在客户端算好服务端验证的么?除非怪的AStar,服务端用C模块实现一下便可。关于你说的AOI,是有点计算量,可是Astar, AOI的代码量,在整个服务端里面少之又少吧。大部分仍是在等待I/O。

       
    26. July 24th, 2015 at 18:32 |  #26
      Reply |  Quote
       

      @hank 
      C++要达到所谓“稳定会用”,起码要花费十年以上的时间,即使你达到了,你也不能保证你每一个队友都达到,以及后续招聘的新人都达到,相反后端代码的话,java程序员只须要三年培训时间,就能写出差很少稳定的代码了。做为技术选型者,你敢选么?

       
    27. July 24th, 2015 at 18:38 |  #27
      Reply |  Quote
       

      @RisingV 
      我并无说 try/catch 有问题,而是 “C++一方面认可做为系统级语言内存管理应该交给用户决定,一方面本身却又定义不少不受用户控制的内存操做行为”,属于 “语言逻辑出现矛盾”,其余 try / catch 的语言都是接管了内存的,不用担忧半初始化问题,C++接管内存,却又没接管完的状况下,加入了 try / catch,就是一个 “逻辑矛盾”。虽然 throw的时候会自动析构,但不少时候是充满各类坑的,好比对待操做系统句柄这种同进程内不会自动析构的东西。

       
    28. hank
      July 24th, 2015 at 21:12 |  #28
      Reply |  Quote
       

      @skywind 
      一款前公司代理要改版的中國 MMORPG Server, 真的就是將 AStar 寫在 Server 裡, 改版時間不夠就真的只能在 Server 裡優化, 沒時間移植到 Client. 因此這真的不是 c++ 的錯, 就算用 java/luajit/… 寫, 還是有人會這樣寫.

       
    29. hank
      July 24th, 2015 at 21:19 |  #29
      Reply |  Quote
       

      @skywind 
      是否是真的要花費 10 年以上才能穩定會用, 我是不太清楚,雖然我寫程式的時間比不上前輩,但寫 c/c++ 的時間算算也超過 10 年了, 也不敢說自已用 c/c++ 就百分百穩定, 但要說 Java 程序員三年培訓時間就能寫出差很少穩定的代碼, 我只能說穩定不表明正確, 并且也不必定穩定. 主要還是程序員自己對要寫的項目自己是否了解.
      就算前輩前面說的波音公司的笑話,真是用很差 c++ 的問題還是大學生根本不了解飛機程序該注意的細節, 就像我長期在寫遊戲程式, 若是換到去寫股票交易,也許第一天上線股市就大當機也不必定.
      ios/object-c 應該算是穩定的語言了吧,應該比 java/luajit 穩定吧, 但前端同事寫遊戲, 將產品送交測試,程序是很穩定不會崩貴,但操做卻一直有問題, 替他檢查代碼, 發現將 select(fd+1, &fds, NULL, NULL, &timeout) <= 0 一概當做斷線處理… 然後數據讀取方式也有問題, 將代碼修改後就變穩定了, 問題也變少了, 但這要算是 ios/object-c 的問題嗎? 還是該同事是 ios 程序員但對 ios/object-c 其實不懂嗎? 我只能說是他對 TCP 程序該怎麼寫不了解, 因為問他為什麼那樣寫, 回答卻是….. 網路上 copy 來的…
      也許前輩所在的公司在招聘新人時,有有經驗的人能够面試合格的程序人員, 但不是每家公司都有有經驗的人能够面試合適的程序人員, 說真的有時候也許可能連面試官本人經驗都不夠也不必定.
      也許面試進來的人真的寫了 c++ 10 年, 不必定寫的出穩定能用的程序,但寫了 java 3 年也不必定寫的出穩定能用的程序啊, 一切還是在於程序員是否了解自已(要)寫的是什麼東西.

      作為技術選型者, 會先以目標產品、通用技術及現有核心團隊可承載的技術為主, 再以招聘新人為次. 因為真的用了一個現有核心團隊無法承載技術的話, 如何去檢驗招聘的人是否合格? 若是出現問題誰來收尾?而不是以網路上誰說誰說或是那種程序員比較好招聘為主吧(當然若是沒有核心團隊又是另一回事了).
      幾年前在前公司時為了作 PC/android/ios 的真3D遊戲, 但當時的 unity3d 的人員(又要會程序又要會美術)很差招聘, 并且當時的 unity3d 也很差用, PC 端裝機量不足, 在手機上效能也不足.
      團隊的開發人員也不足, 不太可能三個平台分開各寫一個 3D 引擎, 維護三套代碼, 最後的作法是用移植 irrlicht 在 PC/android/ios 用 c++ 開發, 不知道這樣的框架, 以當時的時空背景、環境包含資金, 不知道若是是前輩要如何選擇?

       
    30. July 28th, 2015 at 14:26 |  #30
      Reply |  Quote
       

      就该像java活着动态语言同样完全接管内存
      活着,应该是“或者”。

       
    31. calvin
      July 31st, 2015 at 09:24 |  #31
      Reply |  Quote
       

      牛逼的一说,支持做者!感谢做者分享

       
    32. billowqiu
      August 1st, 2015 at 00:09 |  #32
      Reply |  Quote
       

      文章比较长,没彻底看完,就举点事实吧:
      1:国外大公司google,facebook主流都是c++,其中f更是将php翻译为c++运行
      2:国内大公司B,T主流都是C++
      另外c++11之后的c++不知道用过多少

       
    33. wwwkkkooouuu
      August 5th, 2015 at 22:37 |  #33
      Reply |  Quote
       

      博主有点躁。

       
    34. YYFF
      August 6th, 2015 at 08:01 |  #34
      Reply |  Quote
       

      赞同32楼的,并非你用很差就能说一个语言很差的!

       
    35. August 6th, 2015 at 19:48 |  #35
      Reply |  Quote
       

      @billowqiu 
      1. Google 正是用了不少 C++之后发现有各类问题,才发明 go 来逐步代替 C++
      2. Facebook 主流是 php,把php翻译成C++或者上 HHVM不表明就是用C++来开发,就像你C++编译时先把C++翻译成汇编再送入汇编器,不表明你的代码是使用汇编来写的。

       
    36. August 6th, 2015 at 19:54 |  #36
      Reply |  Quote
       

      @YYFF 
      我最先用C++是94年,那时候你读高中了没?各类语言都只不过是描述事物的一种方式而已,就像物理学,无论相对论仍是量子力学都只是描述天然的一种方式,连相对论都不敢说本身可以100%的诠释天然,C++何德何能敢称本身包打天下?C++就敢宣称本身没问题么?别一说C++的问题就说是使用者本身的问题,不要对 C++ 的问题采起回避和不肯意讨论的态度。

       
    37. leafxt
      August 7th, 2015 at 11:58 |  #37
      Reply |  Quote
       

      这种文章,对国人的软件技术,没有任何指导意义,仍然是远远落后于欧美。

       
    38. Kimi
      August 8th, 2015 at 16:54 |  #38
      Reply |  Quote
       

      不想证实C++有多好,由于我也不怎么用,就像说说文章的问题。
      C++11之后list.size是O(1)。
      cstring的strlen仍是O(n)的呢,是否是证实C没有C++好?
      另外,Gcc所有换成了c++编写。VS,Office,Chrome还有你说的Qt,也是C++写的。
      Popularity上,今年比去年涨了超过60%,因此是在反弹咯?
      70%的速度差是很大的。从没据说过有Java的大型游戏,游戏引擎都是C++和别的语言。并且不少benchmark的结果仍是有好几倍的差距(好比Debian上的 10 tiny examples)。看图示你的图给的是编译好的java代码,跟你说的jit愈来愈快毫无关系。另外你的图都没有引用。

      大型可是特别要求效率的部分用C++在正常不过了。

      另外倚老卖老不是个平等讨论问题的态度。

       
    39. Sai
      August 10th, 2015 at 23:39 |  #39
      Reply |  Quote
       

      其实除了C以外的其余语言,好比Java,python,ruby,RUST,SWIFT,OBJC暗地里也干了不少事情时不知道的。Java还要花额外时间去深刻了解虚拟机呢,还有字节码,否则根本写很差高性能程序。

       
    40. August 11th, 2015 at 12:55 |  #40
      Reply |  Quote
       

      this article is very pertinent about C++.
      can’t agree any more.

       
    41. Adam
      August 11th, 2015 at 16:36 |  #41
      Reply |  Quote
       

      Hi, 像Handle這種東西,實際上在C++中是應該交給RAII來完成的。我也寫過很多語言,像Java的GC不表明file就必定close了,connection必定close了,是嘛。這個實際上也是資源泄露。GC有GC的好處,不過GC也不是萬能的。一個合格的Java程序員,也要能夠考慮到各個情況,將file給close掉。我們做爲程序員呢,要寫有良心的代碼。像前面 @hank 說到的 “問他為什麼那樣寫, 回答卻是… 網路上 copy 來的…”,有些時候,你看上去穩定的Java程序員,其實每天在在網絡上拷貝代碼。同時,看到這句話讓我還想起另一句話 “你但愿Code當中的錯誤被奇怪地Assert或者SegFault了,明確地以這種奇怪的方式告訴你,你的程序有問題呢,還是但愿它慢慢地浸淫,直到有一天你看到的結果和你须要的大相徑庭。” 我引用這個不是說,SegFault是好的,或者是一個優雅的作法,卻是想說,我們寫代碼,實際上還是要對得起本身的良心才是。

      我並沒有特別要保衛C++的意思,我很赞成C++有不少問題。然而,我們是否是對C++太苛刻了。不少語言都有問題,並不是說,我們現在拿到的哪個語言就是沒有問題的,並且“好”語言的定義,也是一個很是不明確的東西。

      不少人也都赞成Javascript也有不少問題,可它還是Web Frontend中使用的最多的語言。TCP/IP在歷史上也不是最好的方案,Unix也不是。並且,就算是當下最“好”的東西,我們始終不敢保證,這也還是未來中,最好的東西。我只能輕聲勸解个人前輩們,或是在後輩們的耳旁細細說道,在期待更好的東西出來並有辦法替代現在的東西同事,我們還是良心地作好我們的事情,就是對這個世界盡了我們本身的力了吧。

      skywind :
      @RisingV 
      我并无说 try/catch 有问题,而是 “C++一方面认可做为系统级语言内存管理应该交给用户决定,一方面本身却又定义不少不受用户控制的内存操做行为”,属于 “语言逻辑出现矛盾”,其余 try / catch 的语言都是接管了内存的,不用担忧半初始化问题,C++接管内存,却又没接管完的状况下,加入了 try / catch,就是一个 “逻辑矛盾”。虽然 throw的时候会自动析构,但不少时候是充满各类坑的,好比对待操做系统句柄这种同进程内不会自动析构的东西。

       
    42. wing
      August 12th, 2015 at 12:09 |  #42
      Reply |  Quote
       

      MySQL核心纯C?博主你可曾看过一眼源代码?

       
    43. 进藤HIKARU
      August 14th, 2015 at 13:30 |  #43
      Reply |  Quote
       

      其实我以为吧,真是秀于林,风必吹之啊…..每次被引入到语言战争的风口浪尖的都是C++

       
    44. billowqiu
      August 16th, 2015 at 17:43 |  #44
      Reply |  Quote
       

      @skywind 
      1:哪里有说明谷歌是要取代c++了;若是是这样的话其新开源的grpc,flatbuffer,pb3怎么不用go重写?
      2:fb的web层是php这个没啥问题,虽然最后仍是转换为c++而不是java;其后台服务难道不是c++,能够参看其开源的各类基础组件(osquery,fbthrift,mcroute。。。)

       
    45. August 17th, 2015 at 18:18 |  #45
      Reply |  Quote
       

      @Sai 
      “其实除了C以外的其余语言,好比Java,python,ruby,RUST,SWIFT,OBJC暗地里也干了不少事情时不知道的。Java还要花额外时间去深刻了解虚拟机呢,还有字节码,否则根本写很差高性能程序。” 你没看懂个人意思,我没说语言不能在背后作事情,而是指出C++的逻辑矛盾:“认可本身做为系统级语言用户能够自由操做内存,另外一方面本身又设定了不少不受用户控制的内存行为”,不像C,干脆没有任何背后操做,也不象java,python,要接管内存就完全接管,不给用户操做。C++为了弥补这个逻辑矛盾作了太多补丁了。

       
    46. August 17th, 2015 at 18:21 |  #46
      Reply |  Quote
       

      @Adam 
      因为 C++ 并无强制用户对各类资源采用RAII,而且封装了大部分 RAII,这样一个不严密的定义,致使这里极度容易失控。不出问题则以,一出问题就把人腿炸飞了。

       
    47. August 17th, 2015 at 18:32 |  #47
      Reply |  Quote
       

      @wing 
      别看那些周边代码,你看看 libmysys,libmysql,regex,myisam, sqlcommon, strings, vio 这些基础核心库是否是纯 C的?MySQL 的 C++代码也只是创建在这些核心库之上的一层应用逻辑而已。相似胶水语言的做用。你别看到两个 .cpp/.cc 文件就以为人家是用 C++ 写出来的了。

       
    48. August 17th, 2015 at 19:14 |  #48
      Reply |  Quote
       

      @billowqiu 
      这是历史问题,新事物代替旧事物是有一个过程的,在这个过程当中,旧事物并不会立马存在,它还会持续存在一段时期。Mozzila弄rust来代替C++本身也并非一晚上之间就能停掉全部C++项目,只是说无论 go 仍是 rust 或者 java 他们的出现使得无论前端后端,原来不少必须用 C++ 的地方有了更好选择,他们会在将来逐步在各个领域替代 C++ ,使得 C++ 的应用范围在将来变得更窄,而能更好的无缝同 go/rust 整合的,就是C,不是 C++,就是这么一回事呀。

       
    49. August 18th, 2015 at 01:48 |  #49
      Reply |  Quote
       

      @Kimi 
      你若是以为 Chrome是 C++ 开发的话,你能够打开:chrome://credits/# 看看,chrome用到多少底层库?这些底层库有多少是用纯 C开发的?至于 chrome自己,GUI呀,我已经说的很明白了 “C++适合开发 GUI”。

       
    50. Passw0rd
      August 18th, 2015 at 21:05 |  #50
      Reply |  Quote
       

      啥时候都成java了
      腾讯 畅游 盛大 巨人
      这里面4个公司 我待了3个 80%以上服务器是c++写
      要是真的听你的改用java
      只能去小公司了

       
    51. Art
      September 20th, 2015 at 08:38 |  #51
      Reply |  Quote
       

      彻底不懂C++,可是聽說V8是C++寫的,沒錯的話請在請在清單裡留個位置。

       
    52. cexer
      September 24th, 2015 at 20:29 |  #52
      Reply |  Quote
       

      “要不要出来黑一下C++呢?呵呵呵”,黑C++黑出了满满的优越感啊,说得好像你是王重阳刚从古坟爬出来同样啊。粗略扫了一遍,长篇大论的,确实擦到了一些黑边,惋惜都是隔靴搔痒,大家这些C++黑总是黑不到点子上,让我很着急啊。另外这样长篇大论的,怎么也要弄几个成语、段子调和一下吧,如同嚼蜡通常,实在看不下去了。另外问一下,楼主这个排版还成啊,用什么软件写博呢?

       
    53. @anonymous
      December 10th, 2015 at 19:52 |  #53
      Reply |  Quote
       

      其实java只慢705是不许确的,好比高频程序,通常如今都是亚微妙级(千万分之几秒)完成收到市场信号到发送出指令单。用java作,是达不到的,至少慢几百倍。

       
    54. @anonymous
      December 10th, 2015 at 19:54 |  #54
      Reply |  Quote
       

      在google, facebook,性能敏感的系统仍是大量用c++开发的,这几家界面倒基本不用c++。另外目前c++的主要战场是高性能计算,金融,图形学,给得都挺高的。

       
    55. tearshark
      February 8th, 2016 at 17:22 |  #55
      Reply |  Quote
       

      C最大的黑点就是出现了C++。 并且,Cpp一直以来保持本身首先是C,而后才++。也就是说,c有的优势,cpp所有具备!做者也就是那种手里有锤子,眼里都是钉子的货色而已。用cpp的时候,眼里只有oop,连其祖宗c都看不见。当发现cpp这把锤子敲不出洞来的时候,又企图用c这把锤子敲遍天下。 拿cpp跟Java比还有可比性,跟lua/Python就没有可比性。cpp应该是跟lua/Python共存的,就像c与他们友好相处同样。 至于他碰到那个800k的cpp项目,我想,原做者用c也会写出800k的代码来,问题照样是问题,不会由于换了语言就好转,只会由于换了人而获得改善。 另外,cpp的继承未必是为了oop,不少时候也是为了内存布局。什么隐式构造啥的,一个宏就搞定的,非要计较半天。c作值拷贝也同样的有这个问题。 而c++的模版,重载等功能的好处一点不提,难道是做者其实根本不懂这部分? 这个c++黑得没水平,缘由无他,拿c来对比。

       
    56. tearshark
      February 8th, 2016 at 17:27 |  #56
      Reply |  Quote
       

      @RisingV 
      做者根本不知道c也有setjump函数,结果跟try-catch同样的效果

       
    57. February 9th, 2016 at 20:38 |  #57
      Reply |  Quote
       

      @tearshark 
      首先友情提示下,是 setjmp/longjmp,不是 setjump,别拼错。其次讨论问题就是论事,别摆谱说啥我以为你不懂啥,你去看下什么书,要摆谱的话谁都会,2000年之前我就用过setjmp了,那时你开始学编程了没有?最后,C是有longjmp,但只是个辅助功能,不是语言级特性,这是有根本区别的,除了大量递归降低的编译器外,你见过几个开源 C项目在大规模使用 setjmp ?你又见过几个开源 C++项目不使用try-catch。

       
    58. flanker
      February 25th, 2016 at 10:30 |  #58
      Reply |  Quote
       

      你94年出道,另外俩人何时出道没交代清楚,反正我看完那段的没感受C + Python有多好,却是以为你比他俩强太多。这根本不是语言问题啊,我敢说确定有人不服,坚信C++牛人比你作的更好,并且你只字未提这个项目中C++到底弱在哪,吵架每每就是这么开始的……

相关文章
相关标签/搜索