知乎上關於c和c++的一場討論_看看高手們的想法

余天升

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

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

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

我以爲@余天升說的已經相對完整了。可是我以爲你們的回覆仍是偏片面了一些。並且部分回覆的火力主要集中在評價這兩種語言上，實際沒有回答LZ的問題。

首先，應該從開源社區的風格來講，「一個大集市」我認爲是一個比較恰當的比喻，一個吵吵嚷嚷的地方，必然每一個項目均可以決定本身項目的開發方式。因爲如今彼此之間相互依賴的開源項目大多數都是以Linux平臺爲開發對象，因此天然和Linux平臺自身提供的技術解決方案保持一致是一個比較容易想到的技術策略。

其次，由於Linux社區中的領軍人物對C++抱有顧慮（先不談這個顧慮是不是正確的），致使Linux社區對C++的顧慮比較大。

那麼LZ的問題就能夠轉化成開源社區對C++的顧慮到底是正確的，仍是錯誤的？個人見解是既正確，也錯誤。而緣由都在於 精英治理。

因爲Linux內核，以及核心的GNU軟件，開發者都是技術上首屈一指的精英。因此他們的產品目標，和第三方公司基於Linux平臺開發的軟件產品目標，略有不一樣。包括 Linus Torvalds在內的精英們都懼怕由於很差的代碼而「毀掉」一個優良的做品（固然還有其餘的因素）。

而反觀一些商業上比較成功的軟件，並無過度強調技術性上的「純粹性」，而是更多的以商業利益爲導向，我認爲他們的成功很大程度上是由於他們深入認識到 人的思惟很容易將大的問題作分解，可是比較難將小的解決方案組合成大的解決方案。而在這方面， C++應該比C更有優點，更能經過接口、經過封裝下降產品各個部分的複雜度，不只使開發者可以更容易的進行開發，也更可以讓需求分析、設計更容易貼近用戶實際的使用方式，而不用過度考慮其實現形式是否可以承載。

總之，這兩種語言更大的區別我以爲在於設計的哲學，正是因爲這種哲學上的不認同，致使了開源項目更多的使用C而不是C++。

李垚

《C專家編程》第二章《這不是Bug，而是語言特性》裏有一句話：

它（C++）對C語言中存在的一些最基本的問題沒有什麼改進，而它對C語言最重要的擴展（類）倒是創建在脆弱的C類型模型上。

第十一章《你懂得C，因此C++不在話下》裏還有一段話：

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

vczh

STL做爲一個模範放在那裏人們都不看，非要去寫

披着C++外衣的C語言
披着C++外衣的java

中槍踩坑學不會都是正常的。這根本不是C和C++哪一個好的問題，是大衆對C++的誤解形成的。在用C++的時候，本身水平不高，就不要去用C的部分。都是由於人類的意志力太脆弱，才形成這麼多問題的。

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

不過話說回來，我以爲是由於如今牛逼的一幫人都太老了，可是尚未脫離崗位，因此廣泛有這些想法。咱們組有一個超厲害的在M$幹了二十幾年，剛開始進來就用匯編寫Fortran編譯器的菊苣說，他仍是不太喜歡封裝得太多的東西。不過人家說得好，這只是一個喜愛問題，根本不是什麼好什麼很差的問題。等之後CPU的核變得跟GPU同樣多的時候，C語言就只能成爲負擔了。

Wilson Xu

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

緣由：對於面向對象的編程語言，除C++外還有許多更好的選項，好比Ruby、Python、PHP和Java（全都比C++排名先前）；相反， C的代替品很少。

Thanks 余天升

白順龍

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++畢竟是需求推進起來的，因此仍是符合了開發的須要。

Dion

（1）C++比C多了不少特性，讓用C++寫出來的代碼容易不三不四。
從風格上來講，鍾愛C的程序員可能不喜歡。

（2）兼容性。
雖然C++在絕大部分狀況下是能夠兼容C的，但在某些狀況，仍是不得不使用 extern C 這樣的代碼。

（3）我仍是認爲 C++ 比 C 優秀不少，若是你能很好地駕馭它。
C++ 也是在不斷改進（ANSI C9九、C++0x），以及很早就有了 Boost。
C++ 大師 Bjarne Stroustrup 回答過不少人的一個疑問，大體就是說「C++特性太多了，變得很臃腫，你會不會考慮裁掉一些特性」。他給的答案是「不會，不管是異常、多重繼承、仍是RTTI」。
緣由很簡單。若是說多重繼承會帶來問題，難道C的指針不會嗎？仍是那句話，只要你能很好地駕馭它！

Bill Cheng

就我我的來講，做爲一個C++程序員，我永遠是被C程序員擺在瞧不起的位置，因此開源軟件這種證實程序員榮譽的東西，怎麼能讓那些高傲的人低下頭來使用C++呢……
提及來，本人一路低頭，從C++學到JAVA再到OB-C……愈來愈被同行瞧不起……

任衛

我認爲就是推廣，C原本接受度就更好，各類編譯器所有能夠編譯，任何項目均可以借鑑，並且C更簡單易維護。C就是首選。不但要首選C，如有可能要作到Clean-C.
我以爲可推廣性考慮徹底擊敗linus和大鬍子

路飛

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

另外，開源項目不少是基礎類庫，而 C++ 在不少平臺缺少統一而穩定的二進制接口，沒法作到二進制複用。（很遺憾，像 Boost 這樣可貴一見的著名開源 C++ 項目，在不尊重二進制接口的穩定性這一點上，又是臭名昭著。）那麼，從節約用戶的編譯時間和環保的角度考慮，開源項目採用純 C 而不是 C++ 也是有理有據的。

Snow

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

匿名用戶

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

牟小峯

c++太複雜了，c++寫的庫也很複雜，好比stl和boost，調試不方便，不如c清晰簡單直接。

宋業文

C相對於C++而言簡單、快速、靈活，C++ 複雜到超出絕大部分精英程序員的控制，而對他們而言用C一樣能夠實現優雅的繼承、封裝和多態。C++ 側重於考驗一我的的架構能力，而這種能力對程序員有着很高的要求，稍有不慎，就會傷到本身，還不如用C來實現更完美。

Peter Zhang

C++ 複雜的有點二

許新星

雖說面向對象給了程序員貼近顯示的思考模型，可是在代碼中，一些違反常識的事情仍是會發生。實際模型和代碼模型會有微妙的差異。純粹的面向對象還比較好處理，一旦用錯也能夠有一種回到正確模式的傾向。可是c++的面向對象一旦用的很差，或者說用錯，各類補丁，不合格的代碼，非面向對象的代碼就會添加進來，最後致使項目代碼混亂，不可維護.....

陳天楚

我的觀點，c++的特性比c語言要多得多，若是是一羣人共同維護一個項目，頗有必要先坐下來定下一些規範：哪些庫哪些特性能用，哪些不能用。要否則各自都看不懂對方寫的代碼。
而參加開源項目的程序員，坐下來溝通的機會相對少一些，並且熱衷於開源活動的人們彷佛都比較愛好自由，不容易達成一致的意見。
因此乾脆選擇特性少一點的c語言了。

愛走小路

不能因C++複雜而去唾棄它。。。不少人都是由於它複雜。。因此不用。。那不是語言的錯。是人的智商很差。。對於一個大項目來講。。當你的代碼超過50萬行。。你會發現C++的優點是C永遠不能代替的。。。。。

Guo Marvin

若是你說的開源軟件是作底層，用C寫是必須的。我不討論C++的好處，可是他有作不到的東西。
若是底層開源軟件用C++寫，那麼當須要別的語言來使用這個軟件時，即做爲基礎庫，這時就有麻煩了。用C寫了，不少語言能夠真接和C的庫交互。C++寫的庫，只能C++本身使用。必要時還必須用C處處。這也是爲何操做系統不用C++,不是不想用，而是不能用。

zhenghui zhou

這種問題的答案的首要因素不該該是代碼積累/沉澱/延續嗎？爲何如今人都把精力放在語言特性的比較上？就算不少認識並較好掌握了複雜語言特性的他們，是否有足以拿得出手的項目/代碼能夠分享或者重用。
顯然開源的老祖宗GNU（Gnu's Not Unix）是脫胎於Unix文化，C語言那個時候也已經獲得了廣泛的接受，兼容性也是最好的，用c並延續已有的c的成熟經驗和代碼是最天然的事。幾乎全部流行的linux環境也都是在這個基礎上被搭建起來的，在沒有足夠大的改變開發工具的必要性來推進的話，這麼慣性會延續好久。（其實已經逐步在改變，好比gcc轉換到c++上開發）
任何一個仔細考察和研究開源項目，或哪怕僅僅GNU項目自己的人都會發現其中蘊含的是一個巨大的寶庫。實際上對於從微軟/單機時代走過來的每個人，在介入到網絡（Fidonet/Internet）那一霎時，無不對忽然暴露在眼前的源代碼項目充滿好奇，就彷彿忽然發現了寶藏通常火燒眉毛要去挖掘。
C++乃至後續的項目的確給出了更多的方便編寫代碼的特性，但由於目前使用的馮氏計算機體系結構以及底層都是類Unix的操做系統也決定的的這些特性均可以經過C這個馮氏彙編語言實現，最可能是偶爾稍過繁瑣，這種現狀暫時還不會獲得改變，至少在自動生成代碼的量佔據必定比例之前。
那麼從項目沉澱的角度看，一個最少抽象，又已經有足夠底層支撐的語言是最適合用於開發但願被大衆接受並廣爲傳播的開源項目的。儘管眼下基本上各類流行語言都有很多的相似項目，但若是以必定的質量/價值/普適性閥值作一個過濾的話，基於c的項目可能存活下來的機率是最高的。越是新潮的高級的東西，要不是隻是做爲練手的玩具，要不每每僅侷限於一個某個較窄的應用場景。
因此某些高級的東西，它們的確可以提升某個具體項目的開發效率，但其中提升最多的是那些爲所欲爲的成分，而真正可以拿來重用那部分沉澱/積累的東西並不會所以改變太多。人們每每發現每當一個高級的東西被髮掘出來，可以獲得流行的關鍵每每是其自身究竟積累到何種程度，實際上每次這個積累過程極可能只是一個從新制造輪子的過程，儘管這些個新造的輪子可能表面顯得更加漂亮和光滑。

王翀

沒那麼複雜吧，就是c存在的時間長而已 c自己是優秀的語言，因此一直活到如今。舊時代的項目沒有更換語言的理由但若是看這遠些，互聯網時代出生的開源項目，基本就是使用新興語言了。若是還要高性能，c++是很少的選擇之一其實c++11不應和老c++相提並論的

參考： http://www.zhihu.com/question/20080552