知乎上關于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++，加上兩位大神的抵制，理所當然在開源陣營裡面流行不開。

<a></a>

我覺得@餘天升說的已經相對完整了。但是我覺得大家的回複還是偏片面了一些。而且部分回複的火力主要集中在評價這兩種語言上，實際沒有回答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++中較簡單的一個子集的方法。

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

披着C++外衣的C語言

披着C++外衣的java

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

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

不過話說回來，我覺得是因為現在牛逼的一幫人都太老了，但是還沒有脫離崗位，是以普遍有這些想法。我們組有一個超厲害的在M$幹了二十幾年，剛開始進來就用彙編寫Fortran編譯器的菊苣說，他還是不太喜歡封裝得太多的東西。不過人家說得好，這隻是一個喜好問題，根本不是什麼好什麼不好的問題。等以後CPU的核變得跟GPU一樣多的時候，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++畢竟是需求推動起來的，是以還是符合了開發的需要。

（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++程式員，我永遠是被C程式員擺在瞧不起的位置，是以開源軟體這種證明程式員榮譽的東西，怎麼能讓那些高傲的人低下頭來使用C++呢……

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

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

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

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

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

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來實作更完美。

C++ 複雜的有點二

雖然說面向對象給了程式員貼近顯示的思考模型，但是在代碼中，一些違反常識的事情還是會發生。實際模型和代碼模型會有微妙的差别。純粹的面向對象還比較好處理，一旦用錯也可以有一種回到正确模式的傾向。但是c++的面向對象一旦用的不好，或者說用錯，各種更新檔，不合格的代碼，非面向對象的代碼就會添加進來，最後導緻項目代碼混亂，不可維護.....

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

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

是以幹脆選擇特性少一點的c語言了。

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

如果你說的開源軟體是做底層，用C寫是必須的。我不讨論C++的好處，但是他有做不到的東西。

如果底層開源軟體用C++寫，那麼當需要别的語言來使用這個軟體時，即作為基礎庫，這時就有麻煩了。用C寫了，很多語言可以真接和C的庫互動。C++寫的庫，隻能C++自己使用。必要時還必須用C到處。這也是為什麼作業系統不用C++,不是不想用，而是不能用。

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

顯然開源的老祖宗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++相提并論的

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

繼續閱讀

線性表之順序表的實作

samba伺服器的功能

AOP程式設計_Android優雅權限架構(1)概念基礎，2021金三銀四前言正文大綱正文

面試題解析：你接口測試是怎麼做的？

Effective Java 8:通用程式設計

C++判斷素數、求最大公約數代碼判斷一個數是否為素數求兩個數的最大公約數

【Linux】UDP廣播封包接收速率問題

SequoiaDB巨杉資料庫C++驅動概述

OOM三種類型

工廠模式-三種類型

【遞歸】高效率求2的n次幂

win10本地scala和spark安裝安裝scala安裝spark

Linux裝置模型（中）之上層容器

scala (3) Function 和 Method

PowerPC平台 Linux移植三

hdu7108哈希