C++之父Bjarne談C++在2005年(轉)

C++之父Bjarne談C++在2005年(轉)[@more@]現在我們仍然很難估計C++程式設計師的數量，但在2003年，IDC報告說有超過300萬的全職C++程式設計師，這個資料還是比較可信的。雖然我不能夠精確地計算，但是我所擁有的所有指標都顯示，C++在經過前十年（1985－1994）的爆炸性增長之後，後十年（1995－2004）其使用人數一直在穩定地增長。我還沒有經歷過其增長停止的時期。我猜想，雖然面對競爭產品的有力宣傳和肆無忌憚的促銷活動，它仍然穩定增長的主要原因在於：在這個時期中C++語言保持著穩定性（stability）。在這些年頭中，這種語言的實現有了很大的改善，其類庫的數量、質量和複雜程度都有所增長，同時我們對如何使用C++的理解也進一步深入了。但是，1995年D&E中描述的這種語言我們現在仍然在使用。標準的C++擁有足夠的特性，它能夠適應十年中程式設計技術和應用程式的增長，其穩定性也允許它實現跟上潮流。

那麼，這些C++程式設計師到底在做什麼事情呢？他們在編寫哪種型別的應用程式？他們使用了哪種程式設計風格？我不知道，誰也不會知道。同樣，與C++程式設計師太多了以至於無法估算類似，不同的應用程式領域也太多了，某個人需要掌握的程式設計風格也太多了。有時候我們會聽到別人說"C++應該這樣使用"--這樣的表述一般都是痴心妄想，它們來自於非常有限的經驗。我們在與很多人一起玩"盲人與大象" 的遊戲。有些人已經閱讀了一百多萬行程式碼，編寫了成百上千行C++程式碼，讀過C-vu、C/C++ Users Journal等雜誌中的所有文章，讀過所有優良的C++書籍和許多劣質的書籍，讀過所有的與C++相關的論文，並在C++新聞組中"居住"了很多年。這種人很少，即使是這樣，他們也只碰到了其表面。這種人一般都是最後發表簡單概括的。實際上，我聽到的最簡潔和自信的概括（包括正面的和反面的）都來自於那些幾乎沒有C++經驗的人--無知是福。

當我試圖理解如何使用C++的時候，我首先考慮下面兩個方面：

·應用領域

·程式設計師（設計師、軟體產品公司等）的成熟度

編寫實時（嵌入式）系統的程式設計師與編寫專用的資料庫業務程式的程式設計師所關心的內容是不同的，他們與編寫高能物理（high-energy physics）應用程式的程式設計師所處的環境也完全不同。我發現聽取新應用領域的程式設計師的想法並向他們學習是有好處的。

很難存在某種東西跨越所有應用領域都有意義。但是可以說某種東西（跨所有應用領域）是成熟的。從高層次的角度來看，理想的程式語言可以表達為：

1. 在程式碼中直接地表達概念

2. 在程式碼中直接地表達概念之間的關係

3. 在獨立的程式碼中表達獨立的概念

4. 自由地組合那些表達概念的程式碼，無論這種組合是否有意義

此處的"概念（concept）"與"想法（idea）"的意思大致相同，並且可以參考我們所命名的任何東西、在設計時出現在黑板上的任何東西、在我們的課本中描述的任何東西，等等。

我"測評"成熟度主要基於人們如何把這些想法應用到產品程式碼（也就是受現實條件約束的程式碼）中。如果某些人使用C++的原因主要是把它作為"更好的C"，那麼他們在（上述的四條中的）第一條就遇到了失敗--他們就不能使用類、類層次和引數化（模板）來直接地表達想法以及想法之間的關係。如果某些人堅持把C++僅僅看作是一種物件導向的語言，那麼他們在第三和第四條會遇到失敗--他們會構造厚重的層次，透過一些不適合的依據把無關的概念繫結在一起，排除內建型別和簡單類。

這意味著，即使語言不作進一步改變，也有很多方面有待改善。透過簡單地使用自己計算機上已經安裝的、作為ISO標準C++一部分的工具，大多數人就可以改善他們的程式設計效率、減少錯誤率、提高執行時效能。如果你沒有試用過STL，那就試試吧。也許它不能嚴格地滿足你的需求，但是它是標準的，並且演示了 "現代的C++"中的很多關鍵技術，你可以使用這些技術來解決問題。我曾經指出的教育的題現在更糟糕了：程式設計教育在很大的程度上無法跟上軟體生產方面的變革。由於我最初編寫D&E，我成為了一個專家，在一定程度上助長了這種倒退趨勢。

那麼這些C++程式設計師到底在做什麼呢？這是你可以想到的："普通的PC業務應用程式"、嵌入式系統、電子商務、遊戲、科學計算、網路軟體、作業系統、裝置驅動程式、行動電話等等。在繼續之前，我建議你看看我持續維護的一個小列表 。我個人特別喜歡"冒險和與眾不同的"應用程式，它們擁有極端的效能和/或可靠性需求，例如JPL火星漫步者自動驅動系統、MAN B&W巨型船用柴油機引擎控制系統、高度分散式系統（例如多玩家遊戲）的ICE下層構造。