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

  回復(fù)  更多評(píng)論
  

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

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ù)  更多評(píng)論
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

相比而言， C和java都沒這么容易分岔。
尤其是java， 團(tuán)隊(duì)中基本不會(huì)出現(xiàn)不兼容的設(shè)計(jì)， 因?yàn)闆]有什么其他的好的選擇。
  回復(fù)  更多評(píng)論
  

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

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

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

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

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

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


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

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

@airtrack

嚴(yán)重同意！  回復(fù)  更多評(píng)論
  

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

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

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

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

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

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

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

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

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

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

  回復(fù)  更多評(píng)論
  

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

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

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

c++既然已經(jīng)提供了這么多功能，光靠stl、boost、loki這些庫(kù) 是指標(biāo)不治本的，因?yàn)閺倪€是不能從根源降低復(fù)雜度。而且即使是為了治標(biāo)，泛型庫(kù)也不得不使用更加晦澀難懂的語法。大家可以自己?jiǎn)栂伦约海瑥暮螘r(shí)開始看到c++編譯器提示的有關(guān)stl編譯錯(cuò)誤，不頭大的？


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

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


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

  回復(fù)  更多評(píng)論
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

絲毫不懷疑C++的復(fù)雜性，因?yàn)樽约河袝r(shí)候也會(huì)掉到陷阱里。

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

我不太相信這個(gè)。  回復(fù)  更多評(píng)論
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

很不錯(cuò)的思想  回復(fù)  更多評(píng)論
  

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

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

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

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

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

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

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