呵呵,那個帖子里面的意思不是為了說operator<<復雜,我那篇文章主要強調的是C++流輸出對輸入參數結束判斷手段的缺失.那句"天哪"開頭的抱怨,是指編譯器在后面做了很多事情,要全部都了解到,代價太大.

  回復  更多評論
  

模板元就搞死很多人，所以我從來就不去了解它....
C++其實還是比較簡單的，如果我們把一些不用的特性給忽略掉的話
其實很多人只是用到了C++的一個子集，很少人要把所有的C++特性
全搞明白。  回復  更多評論
  

TC++PL
2.9[2] You don’t have to know every detail of C++ to write good programs; §1.7.
24.5[2] Use C++ features and techniques as needed (only); §24.2.  回復  更多評論
  

@那誰
那你是指編譯器偷偷干了什么事情……我記得會自動生成的函數只有構造函數、析構函數、復制構造函數和operator=。其他的都是去調用這4個函數而已。而且自動生成的這4個函數的內容也是調用成員的這4個函數，一直遞歸下去，其實也沒做什么事情。  回復  更多評論
  

@chaogu
建議：學模板元編程之前，先學Haskell，效果顯著，深入淺出……  回復  更多評論
  

@yrj
其實大部分復雜都是為了構造stl而搞出來的  回復  更多評論
  

復雜是相對的。
學習c++語言本身的時間 毫無疑問是比其他類似高級語言要長的。

c++將很多東西交給程序員來控制，
那么很自然的學習的時間就會增加。
程序員在開發的時候 放在語言本身的注意力就會增加，在很多人看來這是一種負擔。畢竟大部分人在寫的程序對效率要求是很低的，他們不需要對內存的嚴格控制對計算機中的事情了如指掌，他們只希望程序能跑起來而已。

每個人的看法是他所處的環境決定的，
技術就是技術，不了解的人對任何事物都覺得復雜，了解的人都覺得很簡單，僅此而已  回復  更多評論
  

此帖必火。最后很可能成為又一輪語言大戰。
我以前是C++/OO的狂熱者，后來有變得不狂熱。其他語言我熟的不多，就拿C做比較。
1、語法相對復雜，語法規則細節太多，越是懂得語法細節越多，寫出的代碼越是往復雜方向靠。記得我以前寫過一篇牢騷貼（強大的BCB），那個移植我的C++代碼到BCB編譯器時所經歷的編譯除錯，就整出了很多語法細節。尤其是參雜了模板的C++。我想，就我以前在C++上的努力而言，不算不懂亂說的人吧
2、帶來的設計復雜，基本上C++會被捆綁到OO上，見到的C++庫越多，了解的設計思想越多，自己做的設計也越來越傾向于復雜，我們的代碼是否真的會面臨這些變化？相比而言，在用C寫庫代碼時，就非常直接，接口設計方式也很簡單。  回復  更多評論
  

功能越多，提供的選擇就越多，我想做的就越多，給我出錯的機會就更多。但給牛人，用好的機會也更多。
在于如何使用，如何選擇。
  回復  更多評論
  

@Kevin Lynx
我才不會挑起什么大戰呢，這里就只談C++，任何比較不同語言的帖子都會被我刪掉的，謝謝。  回復  更多評論
  

@Kevin Lynx
個人認為，C++的庫對于OO的涉及是很少的。由于純虛類寫起來花的字符比較多（這通常是程序員選擇語法的一個重要依據），而且指針也不太方便，而且還有構造函數和析構函數，你會發現C++的庫傾向于不使用繼承，而是用“值類型”的方法來做。譬如STL的容器，復制的時候是會復制內容而不是句柄的，這根C#和Java等的不一樣。

因此C++并不會捆綁到OO上，相反來說比其他的OO語言“更不鼓勵”OO，而鼓勵使用值類型。C++的程序比起其他的語言來說，寫出那種一大堆接口和繼承的概率還是要小的。因為C++可以更加自由地使用不同的范式，當然結合的最好的非combinator莫屬了，這種OO+值類型+模板元編程混合而形成的declarative programming的類庫，都是十分的好用（譬如boost::spirit，還有我寫的那個）。  回復  更多評論
  

@鍵盤的詠嘆調
我認為，C++的stl就是為了解決語言的復雜問題而產生的，結果很多團隊因為怕自己的手下太爛，而且怕自己的手下沒辦法使用統一的編譯器產生的binary，從而放棄異常（更甚者放棄RAII），結果導致STL沒法用，才讓那些程序猿處于水深火熱之中加班的。如果大規模使用stl的話，很多問題都可以解決。

譬如說我聽到為了禁止使用new而不用stl，殊不知stl還有Allocator，你可以寫，實在不行還能重載全局的new/new[]/delete/delete[]/new()/new()[]/delete()/delete()[]呢，雖然比較危險。

C++的一個哲學就是讓類庫盡可能的提供功能，為了達到這個目標，不同的語法就必需盡可能正交，而且功能強大到到處都可以插入callback，從而寫出高質量而且語法優美的類庫了。所以正確的使用方法應該是大規模使用stl和boost，而不是直接使用C++去構造所有東西。  回復  更多評論
  

@陳梓瀚(vczh)
C++的一個哲學就是讓類庫盡可能的提供功能，為了達到這個目標，不同的語法就必需盡可能正交，而且功能強大到到處都可以插入callback，從而寫出高質量而且語法優美的類庫了。所以正確的使用方法應該是大規模使用stl和boost，而不是直接使用C++去構造所有東西。
====================================================
贊同，這段話讓我想起了《C++ 沉思錄》中說的：語言設計就是庫設計，庫設計就是語言設計。  回復  更多評論
  

我覺得只是復雜， 問題還不大。

C++的問題出在給出的特性分了岔。
從留言中就已經可以看出有（曾經）崇尚OO的，和不主張OO的兩派。
當團隊中人數再增加時， 肯定還會出現更多派系。
如果沒能很好的控制， 就很難和諧， 造成四不像的設計。

相比而言， C和java都沒這么容易分岔。
尤其是java， 團隊中基本不會出現不兼容的設計， 因為沒有什么其他的好的選擇。
  回復  更多評論
  

@OwnWaterloo
C++號稱支持4種編程范式，那顯然是你想怎么做都可以了。但是在團隊協作開發同一個組件的時候，接口都是要經過討論的，提交代碼前都要組員review的，設計文檔寫出來還要給其他相關組review的，足以防止這些問題了。我覺得不能把軟件工程上的錯誤怪罪到C++頭上來。

至于說選擇多的東西交給一群沒經驗的人是會出問題的，那這不就證明他們要是能力不足或者不想學這么多東西，就應該去用C#和Java而不應該用C++嗎。  回復  更多評論
  

復雜很大程度上是了解不夠
常見情形：某個程序員對某個特性不慎了解，然后隨意用了這個特性，編譯、簡單測試通過，提交代碼完事。以后出現問題了，接著感嘆下C++真復雜，然后改掉使用特性的代碼。  回復  更多評論
  

@陳梓瀚(vczh)
討論， review什么的， 有一些用處， 但不能全防住。
特別是"團隊換人"的時候。

這些討論不一定會被良好的記錄。
新成員可能就亂來了。

如果是團隊大換血， 可能新的團隊就會覺得現有代碼是坨屎。


>> 至于說選擇多的東西交給一群沒經驗的人是會出問題的，那這不就證明他們要是能力不足或者不想學這么多東西，就應該去用C#和Java而不應該用C++嗎。

沒有經驗、 能力不足、 不思進取、 混口飯吃的， 恰恰占大多數。
所以， C++也只是少數人手中的利刃， 不是誰都玩得轉的。
一部分玩不轉的人， 就把原因歸咎到C++過于復雜。
推卸責任是很常見的心理。
  回復  更多評論
  

@airtrack

嚴重同意！  回復  更多評論
  

@OwnWaterloo
所以那些人堅持使用C++就是個錯誤嘛，有些東西還是C#和java來寫更好一點。不過因此就說C++不好，顯然是他們自己的錯。  回復  更多評論
  

@陳梓瀚(vczh)
如果C++再提供一個"特性"： 可以禁用某些方面的另外的特性。
團隊合作時會不會好一些？

比如看異常不爽的團隊， 直接在構建腳本里， 通過編譯選項把異常的使用給禁了。
看xxx不爽的， 也可以。。。
  回復  更多評論
  

我聽過比較多的關于C++復雜的理論，主要集中在無法根據C++的代碼，判斷生成最終匯編代碼的形式，而C不會有這個問題。很容易就能根據寫的C代碼，腦子里自動生成GCC O2級別的匯編。

關于C++的爭議，最有水平的該是linus早期對其的一些評價。其中就有07年，著名的C++狗屎論：http://lwn.net/Articles/249460/

中文版：http://blog.csdn.net/turingbook/archive/2007/09/07/1775488.aspx

其中的有一段話很有趣：
C++會導致非常非常糟糕的設計選擇。你們這些C++程序員總是一上來就用語言的那些‘漂亮的’庫特性比如STL、Boost和其他徹頭徹尾的垃圾，這可能對你們的程序有所‘幫助’，但是卻會導致：

“——當庫無法工作時無窮無盡的折磨（別跟我說什么STL尤其是Boost很穩定而且可移植性很好，那全是屁話，而且一點都不可笑）

"——低效的抽象編程模型，可能在兩年之后你會注意到有些抽象效果不怎么樣，但是所有代碼已經依賴于圍繞它設計的‘漂亮’對象模型了，如果不重寫應用程序，就無法改正。

”也就是說，使用優秀的、高效的、系統級的和可移植的C++的唯一方式，最終還是限于使用C本身具有的所有特性。項目限制只用C，意味著參與的人不會搗亂，也意味著會得到許多真正懂得底層問題，而不會折騰那些白癡‘對象模型’垃圾的程序員。

  回復  更多評論
  

我發現我剛才發表的帖子 后半部分貌似例題了···，你討論的是C++的復雜性，我寫成了C++和C的優劣性。LZ和各位朋友請自動無視后面那部分。

不過，既然是討論C++的復雜，那我要說句，確實太TMD的復雜了，我看到就頭大·····  回復  更多評論
  

如果一個任務可以用一種簡單的語言10分鐘完成，
為什么我要去用c++ 花一個小時呢？

c++既然已經提供了這么多功能，光靠stl、boost、loki這些庫 是指標不治本的，因為從還是不能從根源降低復雜度。而且即使是為了治標，泛型庫也不得不使用更加晦澀難懂的語法。大家可以自己問下自己，從何時開始看到c++編譯器提示的有關stl編譯錯誤，不頭大的？


至于linus說的 C++會導致非常非常糟糕的設計選擇 我認為不過是嘩眾取寵罷了。任何語言都有其不可克服的缺點，只要你愿意你也可以拿asm把c數落得一無是處。

c++不可能贏得所有人的心，有的項目拿c++很適合，有的項目拿java更好，有的項目或許用vb來的更有效率。至于其他項目管理上的內容，或許各個公司是有各自的考慮的，畢竟從公司角度來說，減少無謂的開發風險是首要的，所以才有了各種千奇百怪的“代碼規范”。


當然，c++標準如果總是十幾年也不更新一下
或許隨著硬件的不斷發展，
止步不前的c++還會漸漸喪失用戶

  回復  更多評論
  

c++的的“復雜”不僅僅在于語法的細節，而是在于”傾向于過分復雜的設計”；如果你是一個人做獨立項目，會覺得C++像瑞士軍刀一樣爽，但是對于團隊合作，我覺得C++是一個災難性的語言。  回復  更多評論
  

“c++其實不適合做大規模可伸縮性的項目”，這話誰說的, Lippman —— MS VC的核心開發者，c++ primer的作者。  回復  更多評論
  

@OwnWaterloo
VC++可以禁用某些語法的……  回復  更多評論
  

@鍵盤的詠嘆調
C++標準剛剛更新了啊，你怎么能說十幾年不變呢  回復  更多評論
  

@wuqq
這是因為VC++沒有實現一套好的ABI導致的。如果C++跟C#一樣，所有代碼都可以無縫放進dll然后結合，那么什么問題都沒有了。  回復  更多評論
  

@wuqq
Windows的存在代表C++還是可以用來做超級巨大的事情然后又不會出災難的- -b  回復  更多評論
  

@鍵盤的詠嘆調
C++的那些stl和boost本質上就是在模擬其他語言的“語法”，所以你怎么能怪罪于他們“不能降低復雜度”呢。就如同一個沒有反射的java，變成了有發射的java，也降低不了什么復雜度的。  回復  更多評論
  

可能是說比較容易出錯。  回復  更多評論
  

@陳梓瀚(vczh)
不知道有沒有人研究過Windows的源碼，但是內核的開發，尤其不適合用C++，不需要過
  回復  更多評論
  

不知道有沒有人研究過Windows的源碼，但是內核的開發，尤其不適合用C++，不需要過多的抽象，不需要面向對象。很多應用，說是C++，其實只是C++一個很小的子集，披著C++外衣的C而已  回復  更多評論
  

@wuqq
這不是問題，一般來說披著C外衣的C++至少都包含構造函數和析構函數，而這兩個東西對于讓代碼變得更加可維護是極端重要的，反而OO那些東西可以沒有，構造函數和析構函數是一定要有的。  回復  更多評論
  

實際上《人月神話》的一個觀點完全可以解釋所謂的 C++ 的復雜性。該書認為一致性對軟件非常重要。要保證一致性，我們并沒有多少選擇：或者在沒有多少限制的前提下三五個人做一個東西；或者在嚴格限制的前提下數十人甚至上千人做一個大工程；此外就是以上兩者之間廣闊的灰色地帶。

不做限制，很難保證一致性；限制太多，妨礙了創造性。限制本身在其被制定出來的時候，展現了一種停滯性，限制這個詞的定義表明了限制本身的演化的遲緩性，這導致了相對的落后。可見限制的副作用是很大的。

但這是一個商業的世界。投資軟件的目的是為了利潤。在一個新興的市場里，創新很重要。那么多的東東都還不成熟，還需要去探索。少數 C/C++ 的高手可以在其中大展拳腳。在一個成熟的市場里，似乎一切都那么四平八穩，控制成為了公司的追求。C/C++ 這么不好控制的東東，當然沒落了。  回復  更多評論
  

@陳梓瀚(vczh)
控制for中的變量的scope？
還是禁用異常？
還有其他的么？  回復  更多評論
  

@OwnWaterloo
禁用RTTI等等。  回復  更多評論
  

@wuqq
很多網站使用asp寫的，那么我們都不用c,c++,c#,java等等任何其他語言吧。  回復  更多評論
  

言之無物，純粹是想騙評論的吧！  回復  更多評論
  

@frankt
擺明了不就是想要在評論討論嗎，何來之騙。  回復  更多評論
  

@陳梓瀚(vczh)
C語言雖然只是C++的一個子集，但是思維方式與C++完全不同，這也是很多人建議把它們看成兩種語言的原因。而析構函數也就是一種管理資源的方式，大部分情況下都是內存管理，如果在C語言設計的應用中引入一種好的資源管理方式，會發現析構函數其實也不是那么重要。  回復  更多評論
  

絲毫不懷疑C++的復雜性，因為自己有時候也會掉到陷阱里。

但是我很懷疑：一個用C++時不停的犯錯誤，代碼質量糟糕，或者在語言特性的框架之內經常感到一些功能實現不了的人如果轉用了java，C#或者腳本語言，那么他寫出的程序水平或者質量就能“自動”的上一個臺階么？

我不太相信這個。  回復  更多評論
  

所謂C++問題多，實際上還是程序員的問題。

以為自己很牛逼，語言的任何Feature都敢用。你不熟的Feature，用了不是找死咩？用出了問題，就開始怪C++。哦，你說你拉不出便便了，就能埋怨這洗手間太高檔了咩？
  回復  更多評論
  

@空明流轉
所以這就是業余項目造車輪的重要性啦，不造車輪，你怎么有機會用這些feature，怎么能讓你的控制能力上一個臺階涅。  回復  更多評論
  

@欲三更
顯然質量還是那么爛的，這個無需懷疑  回復  更多評論
  

@wuqq
問題就在這里嘛，用C實現好的資源管理，還不如C++的構造函數析構函數成本低又容易掌握，何必信仰純C程序呢。  回復  更多評論
  

@陳梓瀚(vczh)
1）C++中的析構函數成本也并不一定比C低，要用析構函數，就必須考慮拷貝，考慮賦值，考慮引用，還有新引入的左值引用。
2）選擇語言，首先要看做什么，再來選語言。但是，“C++絕對是最糟糕的選擇。如果想要真正的高級特性，那就選擇有垃圾回收或者好的系統集成的，而不是既缺乏C的簡約又缺乏C的直接而且沒有重要概念的高層綁定（high-level bindings to important concepts）的東西。” “C++既無法幫助原型化或者簡單的GUI編程足夠簡化從而真正可用，又不是C那樣積極地鼓勵你使用簡單和直接的語言構造的精益系統編程語言。“從現實來看，C++越來越限于某些領域，比如GUI，比如游戲開發。c++優秀的庫并不多，boost是其中的經典，是最優秀的C++ 程序員開發出來的，但是，就這樣，boost中優秀的庫只是一小部分，大部分庫仍然說得上是丑陋。
  回復  更多評論
  

每種語言都會施加它的限制，區別只是：一種是枷鎖式的，一種是水對魚的限制，一種是力不能及式的。有人認為 C＋＋帶來心智負擔，而 C 如何的簡潔。實在很可笑，這就像是在歌頌力不能及式的限制，歌頌古代工匠的智慧同時鄙視現代化機器大生產。不管 C 如何的簡潔和強大，C 的應用領域有多大呢？除了操作系統及其驅動，世上要寫的程序千千萬，操作系統卻屈指可數。
  回復  更多評論
  

@wuqq
成本什么的，你覺得是開發成本重要還是運行成本重要啊。話說回來，C++析構函數的好處在于“我不用管”，從而不會輕易犯錯。如果我要指定哪里要用構造函數析構函數哪里不用，那就回歸到C了。而且調用析構函數也是個普通函數，跟你每次都掉一個函數去free完全沒有區別（還更好，類型安全，異常安全）。

而且，因為“C++是最糟糕的選擇”的同時，你不去選擇C#和Java而選擇C，這就“更加糟糕”了，不是嗎。如果你覺得C已經足夠好了，那顯然使用C++會讓你變得更輕松的同時，你也不會失去什么。所以這個理由完全是不成立的。

一般來說，我很建議人家使用C++的少部分特性，譬如說構造函數和析構函數。你愿意讓編譯器自動調用你的分配和釋放函數好呢，還是你自己在程序的每一個地方都調用好呢。顯而易見。而且C++你其實還能控制它對某個類不要產生構造函數和析構函數的（如果你是一個合格的程序員的話），因此完全無害。你認為呢，為啥使用C++就得去使用高級特性呢，掌控不了高級特性而去使用它才是愚蠢的，我認為僅僅使用構造函數和析構函數，也已經比C要好得多了。因為在我看來，在完成一個穩定的程序的同時，應該讓語言幫助我避免絕大多數問題的同時我還能控制所有細節（非C++莫屬了），而且我還不需要因為語言自動化程度太低而老是加班。

人的時間才是最寶貴的，如果你想讓你的程序變得非常強大，你也不能因此讓自己勞動時間延長太多，而應該果斷選擇生產力更高的語言。然后你只需要相信那些虛擬機做得足夠好就行了。因為那些東西最終會被大公司維護，自動升級，你的所有程序都會得到好處。正所謂一口吃不成胖子，你想自己維護好呢，還是讓一大堆大公司來幫助你維護好呢？不過使用C++，雖然的確是比Java和C#要麻煩一點，只要你是一個合格的程序員，那我相信絕對不會寫得比C差的，最少都能跟C一樣差，不會再差的了。如果你同時用C++和C寫相同的一個程序，結果C++還用得比C差，那只能怪你自己了不是么。當然前提條件是，你只使用你熟悉的特性。  回復  更多評論
  

@wuqq
我從來不會覺得因為C++難用而選擇C#或者Java有什么不對，但是你在需要新特性的同時，又不選擇C#和Java（這才是真正的心智負擔，我不信你的大部分代碼都寫得比人家的虛擬機和編譯器要厲害），而且還是停留在C上，這才是最大的錯誤呢。除非你覺得C已經用的很爽而且不需要加班也能寫出滿足公司要求的程序這也就算了。

再次強調，人的時間才是最寶貴的。你永遠都可以通過使用集群的庫（譬如.net的Task和Parallel等，C語言不詳），然后讓用戶砸錢購買機器組成集群，來使你的程序的性能大幅度提高的。你用C肯定沒用戶買新機器所帶來的提高要顯著，或者根本就沒有提高。  回復  更多評論
  

1）我引用的是linus的的話，我不覺得這句話很容易引起誤解嘛？ 那我再解釋一下，這句話是話，要么你用低級的C，要么你用高級的Java, .net，python之類。
2）關于開發時間，對于現在的系統來說，很多都是多語言混搭的。c語言好處在于API簡單，訪問直接，適于構造專有模塊。
3）我再引用linus的一句話吧：內存管理根本不是問題，重要的是設計。但愿不會引起誤解。
  回復  更多評論
  

@陳梓瀚(vczh)
你好像強調了一點，“你只使用你熟悉的特性”——這個對于C++，一點不難，困難的在于你要保證：你的同事只使用你熟悉的特性  回復  更多評論
  

不是說語言之爭無意義，而說說它很容易陷入無意義的爭論。關于這個問題，我想換一個角度來思考：語言的選擇對于系統設計的影響  回復  更多評論
  

@wuqq
這個命題有問題，我們應該根據目標系統來選擇我們最合適的語言，然后讓團隊們認真學習。

保證沒問題，每一次checkin之前都要review的，每一個critical的設計都有相應的負責人來review的，每一份開發文檔都有相關team的人來review的，每設計一個產品的時候都有人保證如果你們的東西沒有被review過那么就算寫好了都不算的。

有了checkin之前的review，我就不信所有人的知識的并集都不能包含C++的常用特性。大部分時候都源于團隊協作的方法不對——不肯花成本來保證開發質量，從而減少修bug的時間，從長遠的角度來講既可以提高成員的水平，也可以讓項目的總時間變得更快。  回復  更多評論
  

@wuqq
那為啥用了java的人就沒人想要去了解其細節，而C++就偏偏要呢？  回復  更多評論
  

不記得是在哪里看到的了，大意是：
一個優秀程序員要掌握的知識無論使用哪些語言都是差不多的，不同的地方在于：使用C++的話，你必須把它們大部都學會了，你才能動手做一些有實際意義的東西，（否則你將面臨著一大堆的陷阱）。而Java/C#等，則可以把學習的“時間”平攤，在你沒有“完全”掌握這些知識之前，你已經可以做一些實際的東西出來了（雖然這個時候還稱不上是“優秀”的程序員）。
我覺得，C++所謂的復雜性，大約就是這樣。
PS：把Java/C#放在這里并不想引起爭論。但是我想，如果世界只有一門語言的話，大概沒有誰會“抱怨”它的復雜性。要說它復雜，那是比起其它語言的“感覺”。所以，不比較是不可能的……好糾結  回復  更多評論
  

沒有垃圾回收機制顯的比較笨拙。現代程序員都被寵壞了，可以不計代價的申請資源，從不考慮性能問題，c/c++對他們來說顯的太復雜了。  回復  更多評論
  

@唐風
當然不能不比較，但是比較的結果不能是哪個好哪個不好。  回復  更多評論
  

@kevin.c
那些程序猿們不是每天嚷嚷著C#和Java隱藏了太多特性么，有空研究這些的人不是正好應該使用C++么，而且他們又嚷嚷C++太復雜C簡單，那說到底都是抱怨而已。  回復  更多評論
  

你不覺得C++的關鍵字太多了么?
想想Djikstra是怎么說的吧
  回復  更多評論
  

@狐說
好歹人家關鍵字都是B.S.大胡子當年考察用戶習慣最終才定下來的，而且你用變量名的時候如果那玩意兒變藍了，你不心慌么……你不會碰巧用到關鍵字的。

話說回來，不相用的你不去記住就行了，中文字也這么多，沒人抱怨的……  回復  更多評論
  

@陳梓瀚(vczh)
不錯：
不相用的你不去記住就行了，中文字也這么多，沒人抱怨的  回復  更多評論
  

@陳梓瀚(vczh)
你大概沒明白我的意思
Dijkstra的意思是, 如果一個語言解決問題的方式就是再增加幾個關鍵字的話
是很有問題的  回復  更多評論
  

@狐說
關鍵字不是一切，重要的是語法。你看現在C#的關鍵字就很智能，如果某個地方不可能出現關鍵字的話，那個東西就會被分析為一個名字而不是關鍵字，多了也無所謂的。Dijkstra口中的關鍵字跟我們所理解的關鍵字不是一回事，所以還請你仔細體會體會。  回復  更多評論
  

@陳梓瀚(vczh)
2010-07-07 14:19
話說文中的重載應該是替換，在此同時也有重載。非對稱性導致問題多多。在行為描述上更是奇葩，即使在允許的框架上去改變一下這些行為，感覺都挺蛋疼的。  回復  更多評論
  

很不錯的思想  回復  更多評論
  

由于項目調研，看過V8引擎的代碼，用C++寫的，表示非常的漂亮，可是只是兩個人的作品，對于項目人員較多或者人員變動較大，或者人員水平參差不齊的情況，不建議使用C++。  回復  更多評論
  

如果研究過ffmpeg的源碼的話，就能理解C++的語言復雜性給我們帶來的是何種便利。

第一，ffmpeg是C寫的，沒有辦法從語言層面區分API暴露的函數、數據結構與內部使用的函數、數據結構，作者提供區分的唯一辦法是寫注釋，如果用錯了編譯器不會保護你。

第二，ffmpeg的數據結構包括許多指向其他數據塊的指針，導致非常復雜容易出錯的初始化和清理工作，由于前一個問題，哪些部分該由調用者初始化和善后清理也是混沌不明的。我相信目前基于ffmpeg的絕大多數應用程序都或多或少存在著初始化和清理工作的bug。

第三，C語言難以使用基于線程安全的引用計數的內存管理方式，在多線程越來越重要的今天，多線程之間傳遞視頻幀需要大量多余的memcpy。不是說C語言一定不能用refcount，就有一批參與開發者因為不滿于ffmpeg原作者對refcount的保守態度，分出了一個Libav項目，但是原作者對此強烈抨擊，認為這將是一場災難。我也看了Libav的新API，用C語言操作引用計數的數據塊真是很痛苦的。

第四，這或許是個細節問題，但是非常典型。ffmpeg的基本數據結構之一AVFrame，它的最前面是
uint8_t * data [AV_NUM_DATA_POINTERS];
int linesize [AV_NUM_DATA_POINTERS];
后面跟著許多細節數據，如width，height，format等等，但是很多函數卻把它當成一個AVPicture來處理。AVPicture就是只有data和linesize這兩塊，后面的都沒有。所以，無論ffmpeg內部，還是外部調用者，都需要反復在AVFrame*和AVPicture*之間來回轉換。在我們熟悉C++的人看來，AVPicture明明就是AVFrame的基類，多么簡單的關系。

總之，作為C++程序員，看著作者蛋疼地處理這些早已被C++解決了的麻煩事情，只能無奈地抱怨一句：他干嘛不用C++呢？  回復  更多評論