這兩天抽空在審校鄧際鋒（soloist）先生翻譯的Bjarne Stroustrup為Embedded software and systems. 2005寫作的《 Abstraction and the C++ machine model》一文。結合自己一段時間的C++培訓經驗，對C++的抽象有了更多的思考，在此作一簡單總結，與朋友們交流。

為了將問題談清楚，首先來談談抽象（Abstraction）這個詞，wikipedia對Abstraction有如下解釋：

Abstraction is the process of reducing the information content of a concept, typically in order to retain only information which is relevant for a particular purpose.

簡單來說，就是“去粗取精”，或者“去不相關，取相關”。

這“一去一取”的目的何在？wikipedia也給了很好的解釋：

Complexity reduction

Abstraction typically results in complexity reduction leading to a simpler conceptualization of a domain in order to facilitate processing or understanding of many specific scenarios in a generic way

總體而言，前面摘自wikipedia的兩段話非常扼要地說明了“抽象”在我們認識事物過程中所扮演的關鍵角色——推開來說，人對世界的認識，實際上就是一個不斷“抽象”的過程。“抽象”的力量普遍存在于各種學科，各個領域中。當然，具體到各個學科領域還是有一些具體的差別。

好，下面來具體談談C++中的抽象，或者說編程語言的抽象。從最根本性的目的來言，計算機就是對人的一種抽象——當然Turing的這個美好愿望要靠程序員來慢慢實現。編程語言在這個過程中扮演的角色就是將 “計算機容易理解的東西”抽象為“人容易理解的東西”。結合目前主流的編程語言（C++, C#, Java, VB.NET 等），舉些例子具體來談其中的抽象，就是讓程序員：

基本的編程抽象
* 忘掉數據（無論對象/指針/引用）在內存中的地址，將精力集中在數據所表達的類型實例概念上

面向過程編程的抽象
* 忘掉函數調用的壓棧/出棧細節，將精力集中在函數之間的調用關系上

基于對象編程的抽象
* 忘掉對象中數據成員（字段）的內存布局，將精力集中在數據成員對對象狀態的表達上
* 忘掉對象中函數成員（方法）的綁定機制以及this指針，將精力集中在函數成員對對象行為的表達上 

面向對象編程的抽象
* 忘掉類繼承下子類對象中數據成員的內存布局，將精力集中在繼承所帶來的子類化的概念上
*忘掉虛函數相關的虛表vTable結構，將精力集中在虛函數所帶來的動態多態的概念上 

泛型編程的抽象
* 忘掉模板的各種編譯與綁定機制，將精力集中在用一組抽象的概念來表達一組類型的需求條件上

面向組件編程的抽象
* 忘掉組件平臺背后的元數據等機制，將精力集中在組件化模塊所表達的黑盒概念上

這些“忘掉…而將精力集中在…上”的“抽象”放到C#, Java, VB.NET 等其他語言中，很多程序員都可以輕易做到——換句話說，可以不關心“各種抽象背后所映射的底層機器模型”，只關心語言表達的“抽象”，而照樣開發出合格甚至優秀的程序。這樣，這些語言下的程序員基本上遵循下面的學習路徑，就可以成為一個合格的程序員：

掌握語言語法構造–>掌握設計思想（即抽象）–>開發應用程序 或者 程序庫

但是如果放到C++，一個程序員無論如何不能夠做到“忘掉…而將精力集中在…上”的“抽象”，否則連寫出哪怕是正確運行的程序都很難。一個合格的C++程序員必須遵循下面的學習路徑：

掌握語言語法構造–>掌握各種抽象所映射的底層機器模型–>掌握設計思想（即抽象）–>開發應用程序 或者 程序庫

這就是C++中“抽象”的問題！C++程序員無法擺脫“各種抽象所映射的底層機器模型”而將精力單獨集中于“抽象”上——換句話說，C++的抽象性和它的底層性是C++的一體兩面，不能夠像其他語言一樣輕易分開。

那么是什么導致了C++這種獨特的“不夠徹底的抽象”呢？這種“不夠徹底的抽象”到底有什么優劣呢？

Bjarne Stroustrup 在《 Abstraction and the C++ machine model》一文中重復了他在設計C++時一貫的哲學：

* 在切實可行的最高抽象層次上編程 Work at the highest feasible level of abstraction

所謂“切實可行”就是不損及效率，靈活，管理……簡單地說就是C++希望在獲得“抽象”的同時，仍然盡可能地不損失任何效率。C++一路發展過來，確實達到了這個目標。這正是C++“不夠徹底的抽象”之原因。

這種“不夠徹底的抽象”當然為C++贏得了巨大的成功，使得C++成為系統級軟件的首選語言，是任何其它一門語言都無法望其項背，參見這些重量級的軟件http://public.research.att.com/~bs/applications.html。

但這也使得C++在程序員圈子里一直是公認的難學難用。孟巖在C++開源程序庫評話（節選） 中談到用C++寫優秀的程序庫非常難這一事實。可惜只談了“難”的結論，沒有談“難”的原因。事實上，C++并不僅僅在寫程序庫時難，用C++寫應用程序同樣不會輕松–相對其他語言而談，只是C++寫程序庫要同時考慮的“抽象性和底層性”思維力度更大罷了。所有的根源都在于C++這種“不夠徹底的抽象”。

我不知道“C++的抽象性和底層性這種一體兩面的緊密結合”會在多大程度上損傷C++程序員學習的積極性，并從而影響C++應用的popularity，以及影響軟件項目的質量和進度。 但至少對于目前希望成為C++程序員的朋友來講，必須認識到“需要同時掌握C++語言抽象性和底層性”這個事實，才能將C++徹底掌握好，這也是我在目前不管是給企業，還是個人學員講授C++培訓課程時經常強調的。

當然，C++社區也意識到了這個問題，C++0x 也確立了一項“同時為專家和新手提供支持”的原則，參見Bjarne Stroustrup在去年C++軟件技術大會上的發言《C++0x概覽》。但是從目前來看，這個原則貫徹的并不能令人滿意。例如，我不太相信如果一個C++程序員不清楚理解指針，對象，模板，concept（C++0x中的新東西）等所映射的底層機器模型，就能夠輕松寫出Bjarne在《C++0x概覽》一文中最后演示的那個draw_all()的例子——雖然Bjarne Stroustrup期望所有C++程序員都認為它“如此簡單！”

也許我們本來就不應該對C++期望太多，既想讓它有極致的效率來構造系統軟件，又想讓它有純然的抽象來滿足變化無常的一般性軟件開發——世界上好像沒有十全十美的事情，當然也沒有十全十美的語言:)