學習C++語言時，發現C++里面有那么多的tricks，其實日常編程中要用到的trick少之又少，除非你是庫的設計者，否則很多的tricks根本就無需關注，也許C++在最近的幾年會漸漸的走向開發界的***。

讓我們先對“學院派”下一個定義好不好?先問你自己一個問題，你心目中對“學院派”的定義是什么? 以下是一些選項： 1. 傾向于理論美。2. 忽視實際編碼中的constraints(如效率，模塊性、可讀性等等)。

3. 倡導語言律師行為。4. 鉆細節。5. … 我想如果我說C++語言設計強調理論美，所有學過C++的人恐怕都會笑了…正如Bjarne自己所說的，C++設計初期的Rule of Thumb之一便是“不要陷入到對***性的固執追求中”;不過具有諷刺意味的是，后面你會看到，正是這樣的一種哲學帶來了今天對C++的這個誤解。

我猜持這樣一種觀點的人大多對于學院派的定義都是模糊的，一般都介于“提倡鉆語言細節并利用語言細節的做法”、“關注語言特性本身而忽略實際編碼需求”、“對語言細節無休止的爭論”等等之間。

所以，當有人說“C++==學院派”的時候，他的真實意思很可能是：“C++語言的陰暗角落太多，而且C++社群還有提倡對語言角落把握的潛在哲學，就連C++0x的進化也似乎更多關注語言特性，而那些語言特性根本就跟我們實際開發者脫節了…”等等。

 首先得承認的是，在近一個十年的時間內，C++社群的確某種程度上建立起了一種對語言細節過分關注的心態，這種心態毫無疑問是錯誤的，但只有知道這個錯誤是如何來的，才能解開這個結。

而且，就算一時解不開這個結，知道了原因之后才能保持理性的寬容態度，而不是亂發抱怨。一個理性的態度，更有助于良性發展。例如如果C++社群都能明白這種潛哲學從何而來，或許也就會漸漸走向更好的發展了。

那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下實現它只能靠挖標準，這是唯一的途徑。#t#

要不然就得等語言進化，并忍受若干年，誰愿意?況且這個foreach設施還能作占位符，在C++09來臨之前兢兢業業履行其職責，C++09加入內建foreach支持之后只消用正則表達式搜索全局替換，就OK了，沒有任何的升級麻煩。

再舉一個經典的例子：STL里面的traits。其實traits不應該是traits。traits最自然的實現方式應該是C++09的concept。但STL需要用到靜態dispatch技術啊，那怎么辦?要么用traits(增加語言復雜性)，要么不用(顯然不行)。再舉個經典的例子：模板元編程。模板元編程有啥用?日常開發者八輩子估計也用不到。但真的嗎?沒錯，日常開發者并不會直接用到。

但是，由模板元編程支持的各個boost子庫呢?被選入C++語言的TR1的各個子庫呢(間接用到)?那日常開發者用不用學模板元編程呢?不用學，根本不用學，這么復雜的技術學什么呢?也就是點技巧上的東西。那為什么偏有人學呢?待會再說。 還有大量的例子。

其實STL的traits技術已經能夠說明問題了。如果你仔細看一看，你會發現，那些所謂的利用C++黑暗角落的技術，幾乎無一不是出現在庫開發里面的，而之所以出現在庫開發里面，是因為庫開發中的需求驅動的——為了開發出更好的庫。難道你不想用更好的庫? 哦，說到“更好的庫”，肯定會有同學有意見了。