最近寫了一篇關於C++0x Concepts的文章，意料之外地引起了一場小規模口水仗。回各位帖子的同時，回想這些年C++社群的大小爭論，覺得有必要把一些長久以來在C++爭論中出現的誤解列舉出來。
…History became legend, legend became myth …- The Lord of the Rings
哈雷將軍的笑話想必大家都聽過。一句話經口口相傳，每個人都根據自己的主觀意念加以潤色，修補，歪曲…到最後就面目全非。這裡最要害的一環就是主觀意識，在歷史學裡面有這麼一句話，大致意思是歷史其實只存在於人的意念之中;就算完全客觀的事件，通過不同的人的嘴說出來，造成的心理效應也往往不一樣，每個人都會加上那麼一兩個形容詞，駕馭語言能力高的更是能夠舌綻蓮花，而語言本就有自身的力量，其中的遣詞造句對讀者構成的心理影響力便應運而生。甚至於同一句話，用不同的語氣說出來，都會造成不同的效果。同一句話，站在不同的立場上看，也會根本不是同一個意思。比如“C++還算是門不錯的語言”，站在C++擁護者的角度聽是在憐憫加诋毀C++，而站在C++反對者的角度聽卻是抬舉了C++。
在一個長期被廣泛爭論的話題中，幾乎無可避免的總是存在一些Fallacies和Myths。比如動態&靜態類型系統的爭論，據說從圖靈時代就開始了，到現在還有各種各樣的誤解，而且，可以說，時間越長，系統內的Fallacy越多。就連異常(exception)這樣不算復雜的語言特性裡面居然也有一些長期存在的誤解。
至於這些Fallacies和Myths出現的原因很多：有人要“內涵”唬人、有人要維護自己的心理優勢、有人要維護自己的政權、有人要維護自己的利益、有人因為話從別人那裡聽了半句轉述給別人聽的時候按主觀意念補全(誰願意說“我不知道”呢？)、有人干脆就是人雲亦雲… 所以，一句話，在一個靠口頭表達交換信息的社會中，Fallacies和Myths是無處不在的，因為從內心真實想法到外界表現出來的想法之間存在著“口頭表達”這一中間層，後者由主觀意志支配。這裡的中間層可不比軟件工程裡面的間接層，在這個間接層上惡魔可以變成天使，天使也可以變成惡魔;六月飛雪可以變成天降祥瑞，瓢潑大雨也可以變成艷陽高照。Anyway，這展開來就是一個心理學的問題了，不多廢話了，有愛好的可以去看Harry G. Frankfurt寫的《On Bullshit》或者Scott Berkun的這篇短文——“How to detect bullshit”。呃…我說“一句話”了麼？
C++ - Fallacies and Myths C++作為一門被爭論不斷的語言，其中Fallacies和Myths自然不會少。一般來說，一個問題在被大眾爭論中交換的話語數量與其中的Fallacy數量成正比。但一般來說主要的Fallacies就那麼幾個：
Fallacy #1 ——C++社群的哲學太學院派
讓我們先對“學院派”下一個定義好不好？先問你自己一個問題，你心目中對“學院派”的定義是什麼？ 以下是一些選項： 1. 傾向於理論美。2. 忽視實際編碼中的constraints(如效率，模塊性、可讀性等等)。3. 倡導語言律師行為。4. 鑽細節。5. … 我想假如我說C++語言設計強調理論美，所有學過C++的人恐怕都會笑了…正如Bjarne自己所說的，C++設計初期的Rule of Thumb之一便是“不要陷入到對完美性的固執追求中”;不過具有諷刺意味的是，後面你會看到，正是這樣的一種哲學帶來了今天對C++的這個誤解。
我猜持這樣一種觀點的人大多對於學院派的定義都是模糊的，一般都介於“提倡鑽語言細節並利用語言細節的做法”、“關注語言特性本身而忽略實際編碼需求”、“對語言細節無休止的爭論”等等之間。 所以，當有人說“C++==學院派”的時候，他的真實意思很可能是：“C++語言的陰暗角落太多，而且C++社群還有提倡對語言角落把握的潛在哲學，就連C++0x的進化也似乎更多關注語言特性，而那些語言特性根本就跟我們實際開發者脫節了…”等等。 首先得承認的是，在近一個十年的時間內，C++社群的確某種程度上建立起了一種對語言細節過分關注的心態，這種心態毫無疑問是錯誤的，但只有知道這個錯誤是如何來的，才能解開這個結。而且，就算一時解不開這個結，知道了原因之後才能保持理性的寬容態度，而不是亂發抱怨。一個理性的態度，更有助於良性發展。例如假如C++社群都能明白這種潛哲學從何而來，或許也就會漸漸走向更好的發展了。
我用一個例子來說明這一點：你平時遍歷一個數組，或一個容器的時候是怎麼做的？
for(std::vector::iterator it = v.begin(); it != v.end(); ++it) {…} 這種做法很臃腫。其實你的邏輯是“對v中的每個元素，做…事情”，你知道大多數其它流行的語言中都有內建的for_each。那C++中就沒有了嗎？有。STL的for_each算法，於是你寫： strUCt MyOp{void operator()(int& i){…}}; std::for_each(v.begin(), v.end(), MyOp()); 這個方案實際很差。一是你還是得寫v.begin()、v.end()，二是你得為此定義一整個新類。三是這個新類並不在你使用這個新類(for_each被調用)的點上，因為局部類不能做模板參數。 你要的是lambda function： for_each(v.begin(), v.end(), <>(int& i){ …}); 可是C++98沒有。 你要的是內建foreach： for(int& i : v) {…} 可是C++98沒有。
鑒於循環結構是編程中最常出現的結構之一。這個問題其實還是比較惱人的，假如你覺得不惱人可能只是因為你適應性習慣了，這未必是好事。比如每次都要寫std::vector::iterator就很讓人惱火，假如我換個容器，就要修改一堆std::vector<…>。那用typedef行不行啊？行。可仍然還是需要寫一次typedef，我很懶，我什麼多余的無用代碼都不想寫。要知道，每多出一行無用的(並非因表達思想所需要才出現)的代碼，就增加一點維護負擔，這也正是為什麼語言的表達力如此重要的原因。
那怎麼辦？假如我告訴你，C++98裡面其實你也可以寫： foreach(int& i , v){ …} 你怎麼想？ 廢話。當然是求之不得了。有這麼簡潔的表達方式誰還不想用啊。 我需要告訴你的另一個事實是。為了在C++98裡面幾近完美地實現這個特性，有人把標准的角落挖了個底朝天。不，我不是在為鑽語言細節找理由，我只是想告訴你，許多人所認為的鑽語言細節的做法，其實一開始大多是由用戶實際需求驅動的，這個foreach設施被C++程序員們試圖實現了N遍N種做法，可見需求之強烈。可惜絕大多數實現都遠遠稱不上好用，就連現在這個實現的作者也早在03年在CUJ上發了一個實現，也稱不上好用。是後來又契而不捨才實現了最終這個真正好用的版本的。 我想說的是，上面這個美好的foreach，當然人人都想用。但問題是要在C++98下實現它只能靠挖標准，這是唯一的途徑。要不然就得等語言進化，並忍受若干年，誰願意？況且這個foreach設施還能作占位符，在C++09來臨之前兢兢業業履行其職責，C++09加入內建foreach支持之後只消用正則表達式搜索全局替換，就OK了，沒有任何的升級麻煩。
再舉一個經典的例子：STL裡面的traits。其實traits不應該是traits。traits最自然的實現方式應該是C++09的concept。但STL需要用到靜態dispatch技術啊，那怎麼辦？要麼用traits(增加語言復雜性)，要麼不用(顯然不行)。
再舉個經典的例子：模板元編程。模板元編程有啥用？日常開發者八輩子估計也用不到。但真的嗎？沒錯，日常開發者並不會直接用到。但是，由模板元編程支持的各個boost子庫呢？被選入C++0x的TR1的各個子庫呢(間接用到)？那日常開發者用不用學模板元編程呢？不用學，根本不用學，這麼復雜的技術學什麼呢？也就是點技巧上的東西。那為什麼偏有人學呢？待會再說。 還有大量的例子就不一一列了。其實STL的traits技術已經能夠說明問題了。假如你仔細看一看，你會發現，那些所謂的利用C++黑暗角落的技術，幾乎無一不是出現在庫開發裡面的，而之所以出現在庫開發裡面，是因為庫開發中的需求驅動的——為了開發出更好的庫。難道你不想用更好的庫？ 哦，說到“更好的庫”，肯定會有同學有意見了。
C++98都快十年了，標准庫還是只有那一套STL。庫進展緩慢，到現在GUI庫也沒有一個標准，都是四分五裂各自為營。網絡庫也是、文件系統庫也是、日志庫也是…不過這個問題已經是另一個問題了，容後再說。
問題是，“沒有標准的庫”並不意味著“C++的庫不好”，後者也並不意味著“那些晦澀的技巧並沒有提升庫的質量”，這個邏輯上的兩環都不對。實際上，人們所謂的“晦澀而復雜的技巧”其實正是為了提升庫的質量而被挖掘出來的。traits技術提升庫的效率(靜態轉發)，type erase技術使得boost::function可以接受任何簽名為void()的函數(靈活性)，包括仿函數，包括boost::bind後的函數。type list技術使得boost::tuple能夠接受可變數目的模板參數。policy-based design使得可以對一個設施的功能進行正交分解… 就算把所有流行的C++ tricks都列出來，你也會發現，其實它們幾乎每一個都對應了至少一個實際應用。而實際應用需求哪來的？庫設計的需求。但歸根到底，是使用庫的人——終端程序員——的需求。(效率、靈活性、抽象表達力，哪一樣不是終端程序員的實際需求呢？)
再舉個實例，有同學說，我只要寫簡單的代碼。問題是，簡單不意味著單純。簡單意味著在更高抽象層次上面編程，後者是要靠好的庫抽象才能達到的。借用《Extended STL》裡面的一個例子：
DIR* dir = opendir(".");
if(NULL != dir){
struct dirent* de;
for(; NULL != (de = readdir(dir)); )
{
struct stat st;
if( 0 == stat(de->d_name, &st) && S_IFREG == (st.st_mode &S_IFMT)) {
remove(de->d_name);
}
}
closedir(dir);} 這段代碼刪除當前目錄中所有文件。
readdir_sequence entries(".", readdir_sequence::files);
std::for_each(entries.begin(), entries.end(), ::remove); 這段代碼做同樣的事情——哪個更簡單？
那問題是，為什麼發展到後來，“鑽語言細節”成了社群的潛在哲學呢？ 這其實是一個心理學上的問題，跟語言沒有關系，跟C++的初衷更沒有關系。從心理上，在同一個領域，假如另一個人比你懂得更多，你就會傾向於佩服他，這時另一個人懂的東西有多大的用處其實並不那麼重要，人對自己不懂的東西總是有一種敬畏感的。
C++裡面有那麼多的tricks，其實日常編程中要用到的trick少之又少，日常編程絕大多數都以復用庫為主，而那些tricks就隱藏在庫裡面。除非你是庫的設計者，否則很多的tricks根本就無需關注。
另一方面，寫作C++書籍的大多數都是C++庫的設計者，這就給予了許多C++書一個有偏見的視角，大量庫設計中才會用到的技術被介紹出來，而社群對這些牛人又都是唯馬首是瞻的。(其實我覺得一本Bjarne的《The C++ Programming Language》加上一本Herb&Alexandrescu的《C++ Coding Standard》對於日常程序員來說，真的足夠了。)
此外，人總是好奇的，在C++裡面有那麼多的被“發明”的好玩技術，怎麼可能不會有人去追捧呢。另一個動機則是學了這些技術有立竿見影的炫耀效果，比如在論壇上。這可比編寫可維護代碼的才能輕易表現多了——人自然是更傾向於去關注那些更輕易拿來表現和炫耀的東西的。退一步說，就單單是“發明”一項新的語言特性組合運用技巧都能帶來純粹的成就感，因為你又在現有語言框架下作出了一個創舉，你做了別人做不到的。而作為學習者，你可能會因為發現原來自己理解的一塊土地上還有不知道的東西而感到興奮和新奇，這種興奮和新奇感往往是學習的真正原動力。至少，對於我來說，當年讀《Modern C++ Design》時正是這樣一種感覺，我想有和我一樣感覺的人肯定不在少數。
再來，一個是在人前看不見摸不著的編碼能力，另一個是對handy的技巧的把握。作為一個學習者，傾向於學習後者，因為後者學起來更輕易，而且也往往更有趣。學到了之後能夠得到跟解決重大問題同等的成就感——看看《Effective C++》系列受到的追捧就知道了。
再來，當你面臨兩個問題，一個是如何建立一個高質量的庫(大)，一個是如何修正庫裡面的小bug(如vector裡面某個成員函數的異常保證問題)。假如你有一份時間，你更傾向於把它花在什麼地方？人在心理上總是傾向於走“捷徑”的，體現在這個問題上面便是更傾向於對付耍點小聰明就解決的小問題，並獲得甚至並不亞於解決大問題的成就感。小問題的另一個吸引人的地方在於它耗時短，更“趁手”，它不需要你閉關苦苦編碼幾個月弄出一個框架來而且還不一定能成。所以這就給人一種錯覺，C++社群只知道爭論枝節問題，不知道實干庫。哦，不是錯覺，這的確是大部分的現狀，但這個現象其實並不僅僅止於C++社群，這是人心理的共性造成的，這也就是為什麼無論在哪個語言社群你都會看到爭論最多的都是些“小問題”的原因。(當然，無論在哪個學科，也還總是有牛人去啃難啃的骨頭的。但這並不是廣大民眾的狀況。) 以上種種原因共同造就了C++社群的這種心態。
這其實跟C++的“教義”沒有關系。C++假如有教義的話也是實用為上。這種現狀是自發產生的，它的動力來源於人的心理。假如Java語言有各種各樣的特性組合，且這些特性組合能夠某些時候滿足開發中的實際需求的話，也是一樣會出現這樣的情況的(事實上一個小小的Java Closure就已經引起了大量口水了)。某種程度上，LISP裡面用函數來實現自然數系統，也是一樣的道理，你敢說，你第一次看到它的時候，不贊歎？人之常情而已。 那這種哲學對不對？廢話。當然不對。不但不對，而且有害。很多C++日常開發者在學習庫開發技巧上浪費了很多時間，把握了根本用不到的技術，而且這些技術，不如稱為技巧，可能還會隨著語言進化變得根本無用武之地。還不如好好學學如何讓自己的代碼更KISS呢，基本的編碼准則要遠遠重要得多，正如我剛才說的，日常開發，一本《The C++ Programming Languag》加一本《C++ Coding Standard》足夠了。
另外，說到語言進化順便說一句，語言進化的職責之一便是廢黜繁復的技巧，取代以直接表達思想的語言特性。而C++0x真正在履行這一職責。 最後來說一說前面留下來的一個問題：為什麼C++設計的初衷——“不要固執於完美”——某種程度上帶來了這個局面呢？
因為正是因為這種理念的指導，有不少語言特性從理論上都是不完備的：比如有copy語意沒有move語意(有左值引用沒有右值引用)，於是Alexandrescu用Mojo框架來解決;比如支持可變參數的函數調用卻不支持可變參數的模板參數列表，導致用元編程來解決;比如不支持構造函數轉發，導致必須factor出一個公共的initialize函數來;比如不支持強類型的enum，結果用一大堆宏結合類來解決;比如不支持initializer list，結果用復雜的模板技術來實現某種類似的初始化方式;比如不支持auto和typeof，結果用更復雜N倍的模板元編程技術來實現一個模擬;比如不支持內建的alignment指示，導致Alexandrescu在實現類型安全的union的時候用盡了模板元編程技巧;比如不支持內建的foreach，結果借助於詭異的語言角落實現了一個幾近完美的模擬;比如不支持內建的concept，導致使用模板技巧來實現也算能用的concept檢查…這個列表可以一再延長下去，C++中這樣的示例太多了。C++的不完美導致了各種各樣的技巧應運而生，哦，不，應該說，應實際需求而生。這從另一個側面正說明了一點—— C++太需要進化了!
Fallacy #2 ——C++委員會過分關注一些不切實際的語言特性，而不關心標准庫的擴充
比起第一個fallacy來，這個倒輕易解釋清楚了。人家Bjarne在文章和訪談裡面一再強調，C++從來都是把庫設計放在首位的(這句話其實就意味著，是把最終開發者放在首位的——什麼？你難道不用庫？)，但是C++群體是一個分散多樣的群體，而且沒有大公司的財力支持。前者意味著眾口難調(標准化過程困難)，後者意味著不能集中精英的人力(boost庫的開發都是由大家業余時間完成的)來搞出個百萬美元的免費庫來。此外個人用業余時間來開發庫還意味著往往沒有足夠的精力來對庫進行精化改善，導致庫的質量不佳或者干脆停滯(這樣的C++庫案例很多)。比如日志庫吧，沒有一打也有半打，但由於都是個人業余開發，所以沒有精力做到盡善盡美，唯一一個往boost提交的是John Torjo(也是個牛人)寫的，不過一年前被reject之後就沒了動靜。你難道怪人家？人家又不是你雇來的。
但說到底，還是錢的問題，眾口難調還是終究能調的(boost發起的初衷便在於此)。但沒有錢，鬼才跟你推磨呢。 不過好消息是據說boost明年能拿到fund:-) 應該能把boost狠狠boost一把。 至於“C++委員會過分關注一些不切實際的語言特性”就不知從何說起了。首先，前文已經明確說明語言進化的重要性以及實用性，這說明語言進化根本不像人們認為的那樣“不切實際”，而是與實用休戚相關的。其實從根本上，語言進化就是為了帶來更好的庫，以及更好的代碼(包括日常編碼)，這一點跟大伙殷殷企盼著標准庫其實並不相左。此外還有一點就是，討論語言特性比實際去開發庫要花更少的精力，這兩者花的精力其實不在一個數量級上，開發一個庫出來要難得多得多，所以就造成了一種假象——“委員會的那幫家伙只知道倒騰語言”。這個論點錯在了兩個地方，一，倒騰語言是必要的。二，他們並非只知道倒騰語言，只是庫的問題要艱難得多，沒錢，人家難道砸鍋賣鐵給你開發標准庫嗎？
有同學說，我只要一個能用的庫就行了。但問題是，標准庫能隨便嗎？標准庫之所以不能隨便，是因為像這樣受眾極其廣泛的庫可是要負責任的——將會有百萬千萬行代碼都依靠它。假如標准庫裡面有bug，將會出現幾百萬上千萬行workarounds，這些workarounds依靠於庫的bug，為了保持向後兼容性，標准庫甚至都不能修正這些bug。就連STL這樣漂亮的抽象，迭代器區間還是闖了禍。另一方面，假如只是需要一個能用的庫，C++社區有大量“能用”的庫。姑且不說boost裡面的了。
Fallacy #3 ——C++的強處在於什麼都能做
一個最常見的論調就是，java的虛擬機也是C++做的，於是得出結論，java比C++弱，java沒有C++好。 姑且不說“好”的定義標准是什麼。就算java的虛擬機做的，那C++的第一個編譯器還要用C寫呢。C庫裡面的某些成分還要用匯編寫呢。這個論據是站不住腳的。 其實，持這種論點的人是站錯了位置，問錯了問題。
要害的問題不是一門語言能做什麼，因為說到能做什麼，匯編什麼都能做。而是“在某個特定的領域，哪門語言表現更好”，人們的需求幾乎總是對著某個特定的領域的。後者才是真正matter的問題。 從這個角度看，C++的市場其實只在效率這一塊。有人可能會說，那效率這一塊有C啊。問題是，C的抽象機制太弱。寫架構簡單的應用，或者寫一些核心的(如驅動程序)，沒有面向對象結構的程序，輕易。完全可以用C。但涉及到大型系統，比如.NET基層架構，一些3D游戲。必須用到面向對象或基於對象編程的領域，C在代碼組織和抽象方面的弱點就暴露出來了。比如用C和宏來實現所謂OO，就正說明了C的抽象機制的薄弱。
但是，C++的領土基本也就在這些地方了。簡而言之就是所有“效率重要，且同時需要好的抽象機制的應用領域”。因為C++的優勢就是無損效率的實現更好的抽象。 那C++既有效率又有更好的抽象機制，為什麼C++不能取代java、不能取代python，不能取代ruby？或者至少當C++進化到更好的階段的時候，比如C++0x就是一個大的進展(在語言方面)，為什麼作為一門語言，不能取代那些嚴重“偏科”的語言呢？
原因有兩方面。一方面，正因為“偏科”，所以有些語言才能在它們擅長的領域做得更好，乃至做到最好。“偏執狂才能生存”。人們的需求幾乎總是在特定領域的，你說這時候人是願意選用一門專門為這個領域而生的語言(ruby)，還是願意用一門general-purpose的語言(C++)？另一方面，就算C++在抽象機制上進化到了非常好，乃至於能在某些特定領域也表現不菲的話，由於市場早就被別的語言侵占，別的語言已經有了成百上千萬行的代碼基，別的語言的庫已經發展到非常豐富的程度，別的語言的相關人才教育已經一代又一代，所以結果還是沒得拼。 其實，從另一個角度來說，C++何嘗不也是一門偏執的語言呢？C++的偏執就是效率，C的偏執也是效率，但C++提供更好的抽象，因此在這一塊(效率+抽象)，C++比C有優勢。 C++的領土已經鑄成，另一方面，C++的領土在可見的未來也不大可能縮水了。這是C++的現實，這個現實，至少在Bjarne看來，也沒什麼不好，因為它正反映了C++當時設計的意圖——更好的C。我們也不用趕鴨子上架，非拿C++和其它語言比——適用的場合本就不同，沒得比。 Fallacy #4 …
事不過三，就此打住。況且，這三條難道還不夠嗎？假如你想到還有什麼fallacy要補充的，請不吝回帖:) 我會考慮加到文章裡面的:)
