【Scott Meyers】C++5×5斷想之三：C++曆史上最重要的軟體

<script>function StorePage(){d=document;t=d.selection?(d.selection.type!='None'?d.selection.createRange().text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://www.365key.com/storeit.aspx?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t),'keyit','scrollbars=no,width=475,height=575,left=75,top=20,status=no,resizable=yes'));keyit.focus();}</script> 【Scott Meyers】 C++5×5斷想之三：C++曆史上最重要的軟體   C++5×5斷想之其它請參考： 本文出處: http://blog.csdn.net/lxpbuaa/archive/2007/01/11/1480575.aspx (桂枝香在故國晚秋) 原文位址：http://www.artima.com/cppsource/top_cpp_software.html。 譯文發表于《程式員》2007.1。  作者介紹

Scott Meyers ， C++ 頂級權威之一，為世界各地客戶提供教育訓練和咨詢服務。出版有暢銷的 Effective C++ 系列圖書（《 Effective C++ 》、《 More Effective C++ 》和《 Effective STL 》），設計了創新型的 Effective C++ CD ， Addison Wesley 的 Effective Software Development Series 顧問編輯， The C++ Source (http://www.artima.com/cppsource/) 咨詢闆塊專家。布朗大學計算機科學博士，他的網站是 www.aristeia.com 。      在本系列的第三篇文章裡，我将把視線轉移到評選過去最重要的 C++ 軟體上來。 用 C++ 編寫軟體，你需要工具的幫助。在我看來，這些工具曾經是（将來也是）有關 C++ 的最重要軟體。可以想見，曾經出現了不少用 C++ 開發的重磅軟體，它們促使很多人為了以後項目的開發選擇了這門語言，但我不關心這些。這門語言最重要的軟體應該是軟體開發人群使用的最基本的東西：編譯器和庫。可能， C++ 是更為庫編寫而不是應用開發所設計的一門語言。 我選擇的 C++ 曆史上最重要的五個軟體如下，以誕生年份為序： Cfront ， AT&T 的 Bell 實驗室 開發， 1985-1993 。 Cfront 是最早的 C++ 編譯器。它可是真正的編譯器，不過生成的是 C 格式的目标碼。是以将它認作 C++ 到 C 代碼的預處理器是很自然的。很難讓人在調試時不做它想，因為至少在我 1998 年開始使用它時，仍然沒有 C++ 調試器。頭發花白的前輩們當時使用 C 調試器，必須要對付那些讓人精神崩潰的名字（比如，識别調試器裡指向 C++ 源代碼中某個加法函數的 __pl__1Aff ）。 事實上， Cfront 生成 C 目标碼有兩個好處。第一，可以非常容易将 Cfront 移植到新的平台，因為 C 編譯器到處都是。這就促成了 C++ 在各種環境裡的快速傳播。第二，使用者可以觀察編譯生成的代碼，知道編譯所做的工作。當大多數人還是 C++ 新手的時候，通過揭示其工作過程，有助于消除大家對 C++ 的神秘感。它也扮演某種保護傘的角色。不用擔心 C++ 用黑紗蒙住你的眼睛，因為它所做的任何事情都清清楚楚擺在那裡（至少和從前機器生成的 C 代碼一樣清楚）。   在 1990 年前， Cfront 不僅是個編譯器，而且也成了事實上的語言标準。 C++ 誕生于 AT&T ， Cfront 來自 AT&T 的 C++ 小組，是以無論 Cfront 幹什麼，自然是不會錯的。長期以來，其他廠商的編譯器緊跟 Cfront ，以緻 Cfront 的 bug 都被原樣複制。直到《 Annotated C++ Reference Manual 》（ ARM ）釋出， Cfront 的标準色彩才逐漸消退，特别是大家認識到要為 Cfront 加入異常處理機制需要付出巨大努力的時候。 Cfront 的最後版本釋出于 1993 年，但陰魂不散。 Edison Design Group ，一家專業生産最貼近 C++ 标準的 front-end 編譯器的商業公司，在 2006 年 7 月的檔案裡還指出它們的編譯器相容 Cfront 模式。我猜測仍然 Cfront 仍然在一些不支援本地 C++ 編譯器的嵌入式項目中發揮作用，當然僅僅是猜測。 GCC ， GNU 工程 的傑作， 1987 至今。 GNU 很早就進入了 C++ 商業領域，并且釋出了第一個生成本地代碼的編譯器（相對 Cfront 的 C++-C 轉換而言）。多年以來， GNU 編譯器成了跨平台應用開發的不二選擇。事實上，它是一個交叉編譯器，這也使它在嵌入式系統開發領域廣受歡迎。 GCC 本身是一個支援多種 front-end （包括 C 、 C++ 和 FORTRAN 等）和針對各種平台的 back-end 工具的編譯器平台，其 C++ 版本就是廣為人之的 g++ 。 g++ 的早期推動人是 Michael Tiemann 。我不由得回憶起自己曾經送出了一份 g++ 的 bug 報告，很快就得到了 Tiemann 的回應。他提供了新的 g++ 文法，并請我據此重建編譯器，看看我報告的問題是否解決了。我記得問題依然存在，但一個編譯器的作者特意送你一個修改更新檔并請安裝試用，已經難能可貴了。順便提及一下， Tiemann 于 1989 年與人合夥創辦了 Cygnus Support ，我相信 Cygnus 是曆史上第一個提供免費軟體的公司。據說早期的時候， Tiemann 有時會躺在浴盆裡召開 Cygnus 的會議。 g++ 是開源的，這樣 C++ 社群就可免費獲得與 C++ 标準一緻的 front-end 工具。但我從未聽說哪個以 g++ 代碼為基礎編寫的開源工具（如 Lint 、重構工具等等）的解析能力能與 g++ 比肩。有不少可以解析所有 C++ 聲明的工具（比如 gccxml ），但據我所知，沒有哪個工具能同時解析聲明和定義部分（特别是函數體）。是以盡管我于它沒有個人使用經曆，但我懷疑 g++ 的 front-end 是否在完全開源上有所保留。這對于 C++ 開發者來說是不幸的，因為盡管有很多工具可供使用，但其真正威力應該是解析 [ 注釋 1] C++ 源代碼的能力，這是一個難以逾越的障礙。 Visual C++ ， Microsoft 出品， 1992 至今。 VC++ 是 C++ 成功的最大推動力之一，也是延緩 C++ 進步的最大障礙之一。盡管 Bjarne Stroustrup 斷言“沒有人知道大多數 C++ 開發者到底在幹什麼” [ 注釋 2] ，但我基本上不會懷疑如果我将這顆星球上所有 C++ 開發者召集到一起，并要求為他們使用的編譯器投票，我想大多數人都會提到 VC++ 。僅就這點而言， VC++ 已經并将繼續對 C++ 産生重要影響。而且， Microsoft 的旗艦産品（如作業系統、 Office 等）也完全或主要用 C++ 編寫，并用 VC++ 編譯。這也加重了 VC++ 在 C++ 世界的分量。該公司對 C++ 的倚重促使它開發了很多工具和 API 來支援其應用，進而導緻很多 Windows 開發人員也使用這門語言。到了 90 年代晚期，很多人（這讓我震驚甚至恐懼）将 C++ 叫做“ Microsoft 語言” [ 注釋 3] 。 VC++ 在 C++ 領域占據了統治地位。對于大多數程式員而言， Visual C++ 就是 C++ 。 不幸的是在 Microsoft 的 C++ 實作裡，标準的缺失持續了很多年。 1998 年前，這算不上一個問題，因為根本就不存在可以遵從的标準，其他編譯器廠商也是各行其道。然而， VC6 于 1998 年釋出，此時距 C++ 标準完成已近一年。與同類産品相比， VC6 與 C++ 标準差得最遠。當然這在當時仍然不是一個十分的嚴重問題，因為很少有程式員馬上使用 C++ 标準裡的最新特性。糟糕的是 VC6 一直維持到 2002 年（ VC7 釋出），甚至 VC7 編譯器本身也沒有大的改變。在這些年裡，對标準的支援，基本上都是以更新庫（如 STL ）的形式實作，而我們很多人都覺得多年前就應該釋出更新版本。 2003 年的 VC7.1 終于解決了大部分标準相容問題，但在 VC6 至 VC7.1 的六年間，使用 VC6 的跨平台開發者必須因其缺陷付出艱苦努力，最典型的就是通過條件編譯（也就意味着代碼零亂）解決模闆偏特化等問題。不過，很多開發者直到今天仍在使用 VC6 ，他們也得繼續感謝 VC6 小組大範圍忽視标準相容的決定。比如，新的版本在記憶體耗盡時不抛出異常，而直接傳回空指針。 2003 年後， VC++ 不再存在我認為相當嚴重的标準相容性問題，我相信它現在的上司者非常重視标準相容。然而，我在 1998 到 2003 這六年來經常接觸的都是工作（至少就程式設計式而言）中并無特别困難的開發者，是以我理直氣壯地決定将我對 Microsoft 的“警惕”保持到 2008 年——從他們釋出一個“真正的” C++ 編譯器起的六年。 The Standard Template Library ，源自 HP ， 1993 年至今。像 C++ 這類語言的标準庫應該提供一系列常用容器和算法，這個說法并不會讓人格外驚訝，但即便這樣的作品也可能上這個榜。而 STL 對 C++ 的貢獻遠非如此。它引入了容器和算法的設計架構，這樣，僅僅通過疊代器互動就能實作無縫協作。它示範了如何用容器和疊代器替代數組和指針。此外，它還告訴使用者如何擴充架構，允許引入新的容器、算法和疊代類型——它們可以像 STL 自有元件那樣和任何符合 STL 标準的元件一起工作。所有這些都以效率為實作基礎，不考慮經典的面向對象、基于繼承的解決方案，而幾乎完全依賴于模闆技術。它還為 C++ 引入了泛型程式設計。這一切的努力給我們帶來了庫和庫架構設計思路上的轉變，也滿足了那些尋找便利的、可移植容器者的需求。我在《 Effective STL 》（ Addison-Wesley, 2001 ）裡寫到，“我已經程式設計三十年，但我從未發現 STL 的比肩者”。現在已經超過了 30 年，我仍然沒有發現。 Boost 類庫 ，誕生于 1999 年。這項選擇似乎帶點兒欺騙，因為 Boost 實際上不是一個類庫，而是一個收容人們因各種目的和想法而設計實作的一系列庫的組織。是以， Boost 庫在提供什麼以及如何提供功能上似乎漫無目的。然而， Boost 及其庫對 C++ 産生了重大影響，這種影響在未來可能更為明顯。 TR1 中規定的 14 類新功能（其中 13 個已經寫入 C++0x 草案）裡，有 10 個 [ 注釋 4] 來源于 Boost 庫使用者的建議。 Boost 的影響并非偶然。它就是以充當那些可能最終被加入 C++ 标準的庫的實驗床和推動者為目的而創立的。 TR1 對 Boost 的重視已經證明了它的成功，而且 TR2 很可能包納 Boost 中更多功能。 如果在 Google 中搜尋“ C++ libraries ”（不帶引号），你會發現 Boost 排在頭條。這是否意味着人們想到 C++ 庫，就會想到 Boost 呢？我想它至少說明了 Boost 與 C++ 庫的關系是多麼密切吧。   目前，軟體工具已經成為 C++ 成功的關鍵因素，但歸根結底，任何美好的東西都要人來創造。 C++ 是如此，人類任何别的勞動也是如此。在下篇系列文章裡，我将告訴你我認為誰是最重要的人—— C++ 世界的巨人 [ 注釋 5] 。     注釋： 1. 所謂“解析”，我指的不僅僅是建構抽象文法樹，還包括執行隐式模闆執行個體化、解析重載函數調用等。也就是說包括解析和語義分析，不過很多 C++ 工具的威力起點是語義分析的結果。人們常常将這整個過程叫做“解析”。 2.C++ 社群是如此龐大和複雜，以至于無法分析“大多數程式員”的行為。 3. “ Unix 語言”是 Java ，我不知道 Apple 語言應該是什麼。 4. 它們是： reference wrappers 、 smart pointers 、 enhanced member pointer adapters (mem_fn) 、 enhanced binders (bind) 、 generalized Functors (function) 、 type traits 、 random numbers 、 tuples 、 fixed-size arrays 和 regular expressions 。 5. 每個人都知道巨人的力量，但我做名人研究的老婆卻提醒我說，盡管巨人們都力量超群，但在他們的漫漫長路上，更多依靠的是艱辛努力而不是他們天生的神力。這就是他們前仆後繼投身與奧林匹斯山主宰者（宙斯和他的仆從）鬥争的原因。我将把判斷 C++ 世界裡是否存在同樣現象的問題留給你們，如果有，那麼是誰或者說是什麼扮演着奧運會選手的角色呢？