為什麼很多開源軟體都用 C,而不是 C++ 寫成?


STL作為一個模範放在那裡人們都不看,非要去寫

  • 披著C++外衣的C語言
  • 披著C++外衣的java

中槍踩坑學不會都是正常的。這根本不是C和C++哪個好的問題,是大眾對C++的誤解造成的。在用C++的時候,自己水平不高,就不要去用C的部分。都是因為人類的意志力太脆弱,才造成這麼多問題的。

===========================================

不過話說回來,我覺得是因為現在牛逼的一幫人都太老了,但是還沒有脫離崗位,所以普遍有這些想法。我們組有一個超厲害的在M$幹了二十幾年,剛開始進來就用彙編寫Fortran編譯器的菊苣說,他還是不太喜歡封裝得太多的東西。不過人家說得好,這只是一個喜好問題,根本不是什麼好什麼不好的問題。等以後CPU的核變得跟GPU一樣多的時候,C語言就只能成為負擔了。


gcc和clang都是C++編寫的了...


我覺得@余天升 說的已經相對完整了。但是我覺得大家的回復還是偏片面了一些。而且部分回復的火力主要集中在評價這兩種語言上,實際沒有回答LZ的問題。

首先,應該從開源社區的風格來說,「一個大集市」我認為是一個比較恰當的比喻,一個吵吵嚷嚷的地方,必然每個項目都可以決定自己項目的開發方式。由於現在彼此之間相互依賴的開源項目大多數都是以Linux平台為開發對象,所以自然和Linux平台自身提供的技術解決方案保持一致是一個比較容易想到的技術策略。

其次,因為Linux社區中的領軍人物對C++抱有顧慮(先不談這個顧慮是否是正確的),導致Linux社區對C++的顧慮比較大。

那麼LZ的問題就可以轉化成開源社區對C++的顧慮究竟是正確的,還是錯誤的?我的看法是既正確,也錯誤。而原因都在於精英治理。

由於Linux內核,以及核心的GNU軟體,開發者都是技術上數一數二的精英。所以他們的產品目標,和第三方公司基於Linux平台開發的軟體產品目標,略有不同。包括 Linus Torvalds在內的精英們都害怕因為不好的代碼而「毀掉」一個優良的作品(當然還有其他的因素)。

而反觀一些商業上比較成功的軟體,並沒有過分強調技術性上的「純粹性」,而是更多的以商業利益為導向,我認為他們的成功很大程度上是因為他們深刻認識到人的思維很容易將大的問題做分解,但是比較難將小的解決方案組合成大的解決方案。而在這方面,C++應該比C更有優勢,更能通過介面、通過封裝降低產品各個部分的複雜度,不僅使開發者能夠更容易的進行開發,也更能夠讓需求分析、設計更容易貼近用戶實際的使用方式,而不用過分考慮其實現形式是否能夠承載。

總之,這兩種語言更大的區別我覺得在於設計的哲學,正是由於這種哲學上的不認同,導致了開源項目更多的使用C而不是C++


作為開源項目,和封閉項目不同,要盡量支持更多的平台,對開發環境也不能做太多要求和指定。C 語言比較簡單,編譯器穩定可靠。而 C++ 雖然有一個標準,但是實踐中,各個編譯器的實現都不同程度地偏離了標準。這種差別是很惱人的,為項目帶來很多麻煩。這時採用純 C 而不是 C++ 就是一個十分合理的選擇。

另外,開源項目很多是基礎類庫,而 C++ 在很多平台缺乏統一而穩定的二進位介面,無法做到二進位復用。(很遺憾,像 Boost 這樣難得一見的著名開源 C++ 項目,在不尊重二進位介面的穩定性這一點上,又是臭名昭著。)那麼,從節約用戶的編譯時間和環保的角度考慮,開源項目採用純 C 而不是 C++ 也是有理有據的。


開源社區一直都不怎麼待見C++,自由軟體基金會創始人Richard Stallman認為C++有語法歧義,這樣子沒有必要、非常瑣碎還會和C不兼容,並且還帶來不了什麼非常大的好處。

having ambiguous grammar and "gratuitous, trivial, incompatibilities with C (...) that are of no great benefit"

Linus Torvalds也說,C++是一種可怕的語言,而使用它的一大群水平很次的程序員,使得它變得更加可怕。

"C++ is a horrible language. It"s made more horrible by the fact that a lot of substandard programmers use it"

C++本身的語法是好的,但是過於的複雜,尤其像繼承這些特性被亂用了以後,面向對象的那些優勢會在那些質量糟糕的代碼前面完全喪失,有時候還會使得代碼非常費解。

容易被誤用語法特性而可能會變得很糟糕的C++,加上兩位大神的抵制,理所當然在開源陣營裡面流行不開。

參考: http://en.wikipedia.org/wiki/C%2B%2B#Criticism


(1)C++比C多了很多特性,讓用C++寫出來的代碼容易不倫不類。

從風格上來說,鍾愛C的程序員可能不喜歡。

(2)兼容性。

雖然C++在絕大部分情況下是可以兼容C的,但在某些情況,還是不得不使用 extern C 這樣的代碼。

(3)我還是認為 C++ 比 C 優秀很多,如果你能很好地駕馭它。

C++ 也是在不斷改進(ANSI C99、C++0x),以及很早就有了 Boost。

C++ 大師 Bjarne Stroustrup 回答過很多人的一個疑問,大致就是說「C++特性太多了,變得很臃腫,你會不會考慮裁掉一些特性」。他給的答案是「不會,無論是異常、多重繼承、還是RTTI」。

原因很簡單。如果說多重繼承會帶來問題,難道C的指針不會嗎?還是那句話,只要你能很好地駕馭它!


贊同@余天升 的觀點。再補充一條:

《C專家編程》第二章《這不是Bug,而是語言特性》里有一句話:

它(C++)對C語言中存在的一些最基本的問題沒有什麼改進,而它對C語言最重要的擴展(類)卻是建立在脆弱的C類型模型上。

第十一章《你懂得C,所以C++不在話下》里還有一段話:

編程語言有一個特性,稱為正交性(orthogonality)。它是指不同的特性遵循同一個基本原則的程度(也就是學會一種特性有助於學習其他的特性)。例如,在Ada中,程序員一旦明白了包(package)的工作原理,也就能夠把這個知識應用於泛型包中。令人不快的是,C++中的許多特性是非正交的。精通C++的某個特性並不能給你帶來什麼線索或向你啟發適用於其他特性的思想模型。大多數程序員選擇了只使用C++中較簡單的一個子集的方法。


這種問題的答案的首要因素不應該是代碼積累/沉澱/延續嗎?為什麼現在人都把精力放在語言特性的比較上?就算很多認識並較好掌握了複雜語言特性的他們,是否有足以拿得出手的項目/代碼可以分享或者重用。

顯然開源的老祖宗GNU(Gnu"s Not Unix)是脫胎於Unix文化,C語言那個時候也已經得到了普遍的接受,兼容性也是最好的,用c並延續已有的c的成熟經驗和代碼是最自然的事。幾乎所有流行的linux環境也都是在這個基礎上被搭建起來的,在沒有足夠大的改變開發工具的必要性來推動的話,這麼慣性會延續很久。(其實已經逐步在改變,比如gcc轉換到c++上開發)

任何一個仔細考察和研究開源項目,或哪怕僅僅GNU項目本身的人都會發現其中蘊含的是一個巨大的寶庫。實際上對於從微軟/單機時代走過來的每一個人,在介入到網路(Fidonet/Internet)那一霎時,無不對突然暴露在眼前的源代碼項目充滿好奇,就彷彿突然發現了寶藏一般迫不及待要去挖掘。

C++乃至後續的項目的確給出了更多的方便編寫代碼的特性,但因為目前使用的馮氏計算機體系結構以及底層都是類Unix的操作系統也決定的的這些特性都可以通過C這個馮氏彙編語言實現,最多是偶爾稍過繁瑣,這種現狀暫時還不會得到改變,至少在自動生成代碼的量佔據一定比例以前。

那麼從項目沉澱的角度看,一個最少抽象,又已經有足夠底層支撐的語言是最適合用於開發希望被大眾接受並廣為傳播的開源項目的。儘管眼下基本上各種流行語言都有不少的類似項目,但如果以一定的質量/價值/普適性閥值做一個過濾的話,基於c的項目可能存活下來的概率是最高的。越是新潮的高級的東西,要不是只是作為練手的玩具,要不往往僅局限於一個某個較窄的應用場景。

所以某些高級的東西,它們的確能夠提高某個具體項目的開發效率,但其中提高最多的是那些隨心所欲的成分,而真正能夠拿來重用那部分沉澱/積累的東西並不會因此改變太多。人們往往發現每當一個高級的東西被發掘出來,能夠得到流行的關鍵往往是其自身究竟積累到何種程度,實際上每次這個積累過程很可能只是一個重新製造輪子的過程,儘管這些個新造的輪子可能表面顯得更加漂亮和光滑。


不能因C++複雜而去唾棄它。。。很多人都是因為它複雜。。所以不用。。那不是語言的錯。是人的智商不好。。對於一個大項目來說。。當你的代碼超過50萬行。。你會發現C++的優勢是C永遠不能代替的。。。。。


從Github的語言排行榜(https://github.com/languages)看來,C比C++多了將近一倍。

原因:對於面向對象的編程語言, 除C++外還有許多更好的選項,比如Ruby、Python、PHP和Java(全都比C++排名先前);相反,C的代替品不多。

Thanks 余天升


因為能用好C++的人比能用好C的人要少。


就我個人來說,作為一個C++程序員,我永遠是被C程序員擺在瞧不起的位置,所以開源軟體這種證明程序員榮譽的東西,怎麼能讓那些高傲的人低下頭來使用C++呢……

說起來,本人一路低頭,從C++學到JAVA再到OB-C……越來越被同行瞧不起……


1 歷史原因, C的歷史悠久,基礎項目多,很多40多歲的大牛也是基本用C用的多

2 C++屬於實驗性質的先驅,很多東西都是在C++裡面廣泛應用起來才推廣的,面向對象,泛型等,另外繼承C的一些不良東西,導致臃腫瑣碎,上手容易,產生高質量的代碼不容易,標準不穩定,編譯器很後時才支持的比較好。

3 Linus說的很對,關鍵是設計,如果借鑒設計模式的一些想法,C一樣可以寫的很好,如果習慣了,開發效率未必會比C++低

4 現代的軟體設計講究模塊化設計,各模塊分工好了,整個項目不必使用同一種語言,C++的生存空間被壓縮不少

5 其實C++在一些大項目上應用還是比較廣的,比如symbian, windows,llvm,zeromq, mongodb, ecos,chrome, ace,qt, flash 在需要面向對象的時候,使用C來做還是有些啰嗦, 可以對比下Gtk裡面的C代碼。google和microsoft很喜歡c++

6 C++易學難精,很容易糾結到語言細節中,而忘了項目。

7 C++還是很有發展前途,一些必須用native code的,如果不是用C的高手,用C++還是寫的快。

8 還忘了一條,C語言都是一個人從頭定義的,標準委員會只是略打個補丁。C++是委員會妥協(商業政治和技術)的結果,所以混亂,標準制定進度緩慢。來自於不同的想法,沒有很強的一致的風格。不過C++畢竟是需求推動起來的,所以還是符合了開發的需要。


開源社區這種熙熙攘攘的地方不適合這種多范型的語言,你要oo他要gp,你用raw array他用stl,花樣太多還都是合理的範式,最後就是和成一鍋粥


我覺得因為c是很多人的第一語言,很多人只懂c,而開源社區的項目一般是憑興趣開始的,所以用c的就多了,然後就形成群體了,影響後來人加入的語言選擇


我認為就是推廣,C本來接受度就更好,各種編譯器全部可以編譯,任何項目都可以借鑒,而且C更簡單易維護。C就是首選。不但要首選C,若有可能要做到Clean-C.

我覺得可推廣性考慮完全擊敗linus和大鬍子


這有什麼好說滴,每個人的年青時代不一樣,60年代的人喜歡鄧麗君,80年代的人喜歡范冰冰,90年代的人喜歡劉亦菲,就如同C,C++,JAVA一樣,然後不停的討論為什麼好為什麼不好,是腰細了腿長了還是臉好看的,其實都是扯談,你年輕荷爾蒙最高的時候無論因為什麼原因恰好遇到的(比如因為學這個比如因為公司用這個比如因為C的書更便宜一點),就是你覺得最好的,


c++過於複雜,絕大多開發者都不能完全掌握c++所有的特性(c++iso文檔有600頁你讀完了?boost你都看懂了?)c++的另一個問題是不少程序員 包括我 在使用時,不少設計是利用了語言的一些特性,造成了設計上的不良。到最後就很難修改了。某牛說過c++是座山,世界上最大的屎山。我認為也是源於此吧。總之c++容易寫出複雜而晦澀也不易修改的代碼,這一切不是c++的錯。但在c++里很容易發生。這是門給iq190

以上人用的語言,但太多iq70的人在用,所以大牛門紛紛不用了。


個人觀點,c++的特性比c語言要多得多,如果是一群人共同維護一個項目,很有必要先坐下來定下一些規範:哪些庫哪些特性能用,哪些不能用。要不然各自都看不懂對方寫的代碼。

而參加開源項目的程序員,坐下來溝通的機會相對少一些,而且熱衷於開源活動的人們似乎都比較愛好自由,不容易達成一致的意見。

所以乾脆選擇特性少一點的c語言了。


C++ 編譯器做了很多額外的工作,如程序員不合格,隱藏很多bug。


推薦閱讀:

軟體開源後,能否有開源和商業化兩種授權?
如何看待國服我的世界裡修改了 forge卻 不開源,無視 LGPL 協議這一行為?
如何看待陳皓在微博上對閉源和開源軟體的評論?
如何更有效地學習開源項目的代碼?

TAG:開源軟體 | 編程語言 | 編程 | C編程語言 | C |