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

  回復(fù)  更多評論
  

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

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.  回復(fù)  更多評論
  

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

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

@yrj
其實大部分復(fù)雜都是為了構(gòu)造stl而搞出來的  回復(fù)  更多評論
  

復(fù)雜是相對的。
學(xué)習(xí)c++語言本身的時間 毫無疑問是比其他類似高級語言要長的。

c++將很多東西交給程序員來控制，
那么很自然的學(xué)習(xí)的時間就會增加。
程序員在開發(fā)的時候 放在語言本身的注意力就會增加，在很多人看來這是一種負擔。畢竟大部分人在寫的程序?qū)π室笫呛艿偷模麄儾恍枰獙?nèi)存的嚴格控制對計算機中的事情了如指掌，他們只希望程序能跑起來而已。

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

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

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

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

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

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

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

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

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

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

我覺得只是復(fù)雜， 問題還不大。

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

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

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

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

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

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

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

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


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

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

@airtrack

嚴重同意！  回復(fù)  更多評論
  

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

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

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

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

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

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

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

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

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

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

  回復(fù)  更多評論
  

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

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

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

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


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

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


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

  回復(fù)  更多評論
  

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

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

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

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

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

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

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

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

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

不知道有沒有人研究過Windows的源碼，但是內(nèi)核的開發(fā)，尤其不適合用C++，不需要過多的抽象，不需要面向?qū)ο蟆：芏鄳?yīng)用，說是C++，其實只是C++一個很小的子集，披著C++外衣的C而已  回復(fù)  更多評論
  

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

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

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

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

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

@OwnWaterloo
禁用RTTI等等。  回復(fù)  更多評論
  

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

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

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

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

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

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

我不太相信這個。  回復(fù)  更多評論
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@wuqq
這個命題有問題，我們應(yīng)該根據(jù)目標系統(tǒng)來選擇我們最合適的語言，然后讓團隊們認真學(xué)習(xí)。

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

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

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

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

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

@唐風(fēng)
當然不能不比較，但是比較的結(jié)果不能是哪個好哪個不好。  回復(fù)  更多評論
  

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

你不覺得C++的關(guān)鍵字太多了么?
想想Djikstra是怎么說的吧
  回復(fù)  更多評論
  

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

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

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

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

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

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

很不錯的思想  回復(fù)  更多評論
  

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

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

第一，ffmpeg是C寫的，沒有辦法從語言層面區(qū)分API暴露的函數(shù)、數(shù)據(jù)結(jié)構(gòu)與內(nèi)部使用的函數(shù)、數(shù)據(jù)結(jié)構(gòu)，作者提供區(qū)分的唯一辦法是寫注釋，如果用錯了編譯器不會保護你。

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

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

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

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