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++到底弱在哪,吵架每每就是這麼開始的……

相關文章
相關標籤/搜索