榮耀,馬皓明譯....
Elden Nelson：如果您現(xiàn)在有機(jī)會從頭設(shè)計C++語言，您會做些什么樣的改變？
Bjarne Stroustrup：當(dāng)然，你永遠(yuǎn)都不可能重新設(shè)計一種語言，那沒有意義，而且任何一種語言都是它那個時代的產(chǎn)物。如果讓我今天再設(shè)計一種語言，我仍然會綜合考慮邏輯的優(yōu)美、效率、通用性、實(shí)現(xiàn)的復(fù)雜程度以及人們的喜好。要知道人們的習(xí)慣對于其喜好有著巨大的影響。
現(xiàn)在，我會尋找一種簡單得多的語法 ?它可能與人們對?#29087;悉?#21644;?#31616;單?#30340;混淆認(rèn)識相悖，我會把對類型系統(tǒng)的侵犯限制在極少的語言構(gòu)造里，并且用明顯?#19985;陋?#30340;語法來標(biāo)識它們。（就象我對對新風(fēng)格的?#36716;型?#30340;處理，比方說，reinterpret_cast<int>(p)就是一個用來描述一種?#19985;陋?#25805;作的?#19985;陋?#35760;號）。這樣可以很容易地禁止不安全的操作。
我還會把核心語言的體積搞得盡可能小一些，包括類和模板的關(guān)鍵的抽象特性，而把很多其它的語言功能放在庫里來解決。當(dāng)然我也會保證核心語言足夠強(qiáng)大，使得那些庫本身也足以用此核心語言來產(chǎn)生。我可不希望標(biāo)準(zhǔn)庫的編寫者依賴于普通用戶無法使用的額外的語言特性。我還努力使核心語言的定義更加精確。
最重要的是，我會在該語言被廣泛使用之前盡可能維持一個很長的醞釀期，這樣我就可以根據(jù)來自真實(shí)用戶的堅實(shí)反饋對它進(jìn)行改進(jìn)。這可能是最困難的，因?yàn)橐坏┯惺裁礀|西明顯出色并且前途光明，它就會被廣為使用，此后進(jìn)行任何不兼容的修正都將變得極其困難。
我相信這些思想與我當(dāng)初設(shè)計C++時的理念是非常類似的，它們同樣也指引著一、二十年來C++的不斷演化。當(dāng)然，我認(rèn)為現(xiàn)在還沒有什么東西能讓我覺得象是?#23436;美的語言?#12290;
Elden Nelson：當(dāng)您設(shè)計C++語言時，您是否借鑒了其他嶄露頭角的對象語言（例如Modula-2）的思想？
Bjarne Stroustrup：在C++的設(shè)計過程中，我吸取了C、BCPL、SIMULA、ALGOL 68、Ada、ML以及其他一些語言的思想。當(dāng)時我知道Modula-2，還知道至少一打別的語言，但我回想不起來Modula-2對我產(chǎn)生了什么直接的影響。
為了回答?#20026;什么C++會是這樣（以及為什么不這樣）?#20043;類的問題，我撰寫了《The Design and Evolution of C++》一書。也就是說，這本書記錄了導(dǎo)致C++現(xiàn)狀的設(shè)計決策、原則以及折中權(quán)衡，我推薦對此類問題感興趣的讀者閱讀這本書。
Elden Nelson：您預(yù)期對C++做哪些增強(qiáng)，會不會刪掉一些東西？
Bjarne Stroustrup：很不幸，雖然有一些東西真的可以扔掉，但恐怕很難刪掉任何東西。第一個應(yīng)該拋棄的東西就是C風(fēng)格的轉(zhuǎn)型機(jī)制和類型截斷轉(zhuǎn)換（narrowing conversions）。就算不禁止，編譯器的作者們至少也應(yīng)該對這種行為給與強(qiáng)烈的警告。我希望能用標(biāo)準(zhǔn)庫中的vector之類的東西徹底取代數(shù)組，但這顯然是行不通的。不過如果程序員們能主動在所有應(yīng)用編程中使用vector來代替數(shù)組，就會立刻受益匪淺。關(guān)鍵是你不必再使用C++中最復(fù)雜難纏的技巧了，現(xiàn)在有優(yōu)秀得多的替代方案。
我沒打算去掉任何大的特性。特別是那些把C++與C區(qū)別開來的主要特性恐怕沒法風(fēng)平浪靜地被拋掉。通常問這些問題的人是希望我挑出諸如多繼承、異常、模板等機(jī)制來接受批判。所以在此我想大聲講清楚，我認(rèn)為多繼承機(jī)制對于一門具有繼承機(jī)制的靜態(tài)類型語言來說是必需的，異常機(jī)制是在大系統(tǒng)中對付錯誤的恰當(dāng)?shù)姆椒ǎ０鍣C(jī)制對于類型安全、優(yōu)雅和高效的程序設(shè)計來說不可或缺。我們可以在語言細(xì)節(jié)方面對這些機(jī)制吹毛求疵，但在大的方面，這些基本概念都必須堅持。
現(xiàn)在我們?nèi)栽趯W(xué)習(xí)標(biāo)準(zhǔn)C++，也正在標(biāo)準(zhǔn)所提供的特性基礎(chǔ)上發(fā)展出更新且更有意思的編程技術(shù)。特別是人們剛剛開始使用STL和異常機(jī)制，還有很多高效強(qiáng)大的技術(shù)鮮為人知，所以大可不必急匆匆地跑去增加什么新機(jī)制。
我認(rèn)為當(dāng)前的重點(diǎn)是提供很多新的、比以前更加精致的且更有用的庫，這方面潛力巨大。例如，如果有一個能被廣泛使用的、更精致的支持并發(fā)程序設(shè)計的庫，那將是一大福音 ?C風(fēng)格的線程庫實(shí)在不理想。我們也就可以與各種其他的系統(tǒng)比如SQL以及不同的組件模型更好地契合起來。在優(yōu)雅高效的庫的開發(fā)方面，數(shù)值計算領(lǐng)域的人們看起來已經(jīng)走到了前面（例如Blitz++、POOMA和MTL，請訪問www.research.att.com/~bs/C++.html）。
有了足夠的經(jīng)驗(yàn)之后，我們就可以更好地決定什么能夠（也應(yīng)該）被標(biāo)準(zhǔn)化。
Elden Nelson：我們正不可避免地走向一個以Web為中心、分布式計算為主流的時代。那么您覺得C++還能維持其地位嗎？程序員們可不可能把若干種專用語言（比如Perl、Javascript）綜合運(yùn)用以徹底取代某一種通用語言？為了配合新的計算模式，C++或標(biāo)準(zhǔn)庫應(yīng)該做出怎樣的調(diào)整？
Bjarne Stroustrup：從來沒有哪一種語言能適合所有的工作，恐怕以后也不會有。實(shí)際系統(tǒng)通常是用多種語言和工具構(gòu)造起來的。C++只是想成為若干語言和工具中的一個，當(dāng)某些專用語言在其領(lǐng)域里特別突出時，它們可以與C++互為補(bǔ)充。也就是說，我覺得如果大多數(shù)現(xiàn)在的專用語言能借助特定領(lǐng)域的C++庫共同工作的話，它們會表現(xiàn)得更出色，而腳本語言通常導(dǎo)致難以維護(hù)的代碼，這或許跟語言選擇關(guān)系不大，可能更是因?yàn)榧敝雽a(chǎn)品盡快推向市場。如此一來，哪還有什么精力考慮程序結(jié)構(gòu)、伸縮性和可維護(hù)性方面的問題？
我不敢肯定未來的代碼是否真的會以Web為中心，就算是直接處理Web的系統(tǒng)也主要是由處理本地資源（比如IP連接）的程序模塊構(gòu)成的。
地理上的分布性以及服務(wù)器軟件對于并發(fā)機(jī)制的高度依賴對于系統(tǒng)的構(gòu)建者來說的確是個挑戰(zhàn)。針對上述問題的一些庫已經(jīng)出現(xiàn)，也許我們將會看到它們最終得以標(biāo)準(zhǔn)化。當(dāng)然，一些原語操作（primitive operations）和保證規(guī)則應(yīng)該被加到核心語言中以提供對這些庫的更佳支持。
總的來說，對于Web和網(wǎng)絡(luò)，我們非常需要一個真正的系統(tǒng)/網(wǎng)絡(luò)級的安全模型。指望下載的?#20197;JavaScript之類的語言編寫?#30340;腳本來實(shí)現(xiàn)這個模型無異于癡人說夢。請注意，我也并沒有宣稱C++提供了這個問題的解決方案。C++被設(shè)計為對所有系統(tǒng)資源提供高效的訪問，而不是為了防止被欺騙。
Elden Nelson：您認(rèn)為C++未來的走向如何？在接下來的10年里它會衰落嗎？或者基本保持現(xiàn)狀，或者演化為某種不一樣的東西？
Bjarne Stroustrup：C++有著極美好的未來。用它你能寫出偉大的代碼。不管被多少敵意的宣傳所攻擊，C++仍將是開發(fā)高性能、高復(fù)雜度系統(tǒng)的最佳語言。據(jù)我所知，還沒有哪種語言能象C++這樣，將通用性、效率和優(yōu)雅有機(jī)結(jié)合。
我沒看到C++有衰落的跡象。在我能預(yù)見的未來里，它的用途還會不斷增長。當(dāng)然，在未來的十年里我們會看到一些變化，但不會象這篇訪談中的這套問題所暗示的那么多。跟每一種語言一樣，C++也會不斷演化。?#35821;言專家們?#35201;求改進(jìn)的喧囂聲震耳欲聾，但是系統(tǒng)開發(fā)者們的基本請求是保持穩(wěn)定。
C++會改進(jìn)，但這些改進(jìn)將是?#32463;驗(yàn)?#30340;結(jié)果而非對?#29378;熱?#30340;反應(yīng)。為了更高效地使用一些新的編程技術(shù)，比如通用編程技術(shù)，可能會增加一些小特性。會有大量的庫涌現(xiàn)，我預(yù)期會出現(xiàn)一些新穎的便利設(shè)施以支持更好的庫。我希望新的擴(kuò)展主要集中在支持抽象方面的一般特性，而不是為支持某些特殊任務(wù)的特定機(jī)制。
打個比方，屬性（properties）是一個有用的應(yīng)用層的概念，但我不認(rèn)為在一種通用編程語言中有它的容身之地。用標(biāo)準(zhǔn)C++的一組類可以很容易地支持這一概念。如果我們感覺那族類對于?#23646;性?#36825;一概念的支持不合口味，我們也不應(yīng)該立刻跑去在語言里增加屬性機(jī)制，而是仔細(xì)考慮如何改進(jìn)類和模板以幫助庫設(shè)計人員盡可能接近?#23646;性?#36825;個概念。也許通過改進(jìn)函數(shù)對象（function objects）機(jī)制能夠給這個問題一個滿意的答復(fù)。
為了使C++在接下來的十幾年中保持生命力，很基本的一點(diǎn)就是不要讓標(biāo)準(zhǔn)C++趕什么學(xué)術(shù)或商業(yè)時髦。人們要求增加的特性中很大一部份通過使用現(xiàn)有的標(biāo)準(zhǔn)C++開發(fā)新庫的方式都可以實(shí)現(xiàn)。還有，事實(shí)上人們渴望得到的很多奇妙的特性已經(jīng)包含于標(biāo)準(zhǔn)C++之中，并且被所有最新版本的編譯器所支持。對許多程序員來說，提高代碼質(zhì)量的最佳途徑不是追求什么語言擴(kuò)展，而是靜下心來品味最新的C++技術(shù)書籍。
Elden Nelson：對于當(dāng)前腳本語言的興旺態(tài)勢您怎么看？特別是Python，與C++相比，它似乎提供了一種更簡單的OO技術(shù)學(xué)習(xí)途徑。
Bjarne Stroustrup：有些語言很不錯。比如Python，我很喜歡。但是我認(rèn)為你從不同的語言中學(xué)到的OO技術(shù)是不完全相同的。當(dāng)然，每一個職業(yè)程序員都要通曉幾門語言，并且應(yīng)該意識到，在不同的語言之中，編程和設(shè)計技術(shù)有著顯著不同。
在我看來，用腳本語言建造的系統(tǒng)與用C++那樣的通用語言建造的系統(tǒng)大不相同。從兩類語言中學(xué)到的技術(shù)區(qū)別明顯。不存在?#21487;以滿足絕大多數(shù)高效系統(tǒng)構(gòu)建所需?#30340;公共OO技術(shù)子集。
Elden Nelson：有沒有計劃對標(biāo)準(zhǔn)C++語言進(jìn)行擴(kuò)充或改進(jìn)，從而為分布式計算提供更好的支持？
Bjarne Stroustrup：沒有，我也不認(rèn)為有這個必要。用更好的庫就差不多能解決問題了。充其量為了支持這類的庫，我們可能會增加一些低級的?#21407;操作（primitives）?#25110;?#20445;證（guarantees）?#12290;
Elden Nelson：將來C++有沒有可能定義一個可移植的二進(jìn)制接口？
Bjarne Stroustrup：如果你說的?#21487;移植?#26159;指跨硬件和跨操作系統(tǒng)，我想答案是no。我們當(dāng)然可以設(shè)計一個解釋器或者虛擬機(jī)什么的，但這樣一來，由于無法以最優(yōu)方式訪問系統(tǒng)資源，C++的能力就會受到削弱。我希望在不遠(yuǎn)的將來能夠看見平臺ABIs（platform ABIs）。例如，有人正在努力為Intel新的IA64架構(gòu)定義C++ ABI（參見http://reality.sgi.com/dehnert_engr/cxx，http://developer.intel.com/design/ia-64/devinfo.htm），我想這些努力會得到用戶社群的強(qiáng)烈支持。
能夠把一臺PC上不同編譯器產(chǎn)生的代碼連接（link）在一起是一件美妙的事。
Elden Nelson：您目前是否正在為其他新語言開展工作？
Bjarne Stroustrup：沒有。我還在學(xué)習(xí)如何使用標(biāo)準(zhǔn)C++，并且進(jìn)行一些分布式計算的試驗(yàn)。我認(rèn)為編程本身遠(yuǎn)比編程語言細(xì)節(jié)有趣。我認(rèn)為只有當(dāng)你有一些東西無法用已有語言合理表達(dá)時，才需要考慮設(shè)計一門新語言。對我來說，絕大部分工作都可以通過C++很好地完成。
Elden Nelson：以?#21518;知之明?#30340;角度來看，您是否認(rèn)為?#20351;一個成員函數(shù)默認(rèn)為非虛函數(shù)?#26159;一個明智的決定？假設(shè)有機(jī)會改變，您會改變這個決定嗎？
Bjarne Stroustrup：也是也不是。
使C++保持生命力的要素之一即是?#38646;開銷規(guī)則?#65306;你無需為你不用的功能付出代價。使一個成員函數(shù)默認(rèn)為非虛函數(shù)會違反這條規(guī)則，還會為?#25552;供高效的具體類型（concrete types）?#22686;加難度。對于那些認(rèn)為?#31867;?#21363;為存在于復(fù)雜層次結(jié)構(gòu)中的大家伙的人們來說，默認(rèn)為virtual是顯然的。一般來講，虛函數(shù)不適合那些關(guān)鍵的小而具體類型，例如復(fù)數(shù)（complex numbers）、points、vectors、lists，以及函數(shù)對象。對于這樣的類型來說，如下方面至關(guān)重要：表達(dá)的緊湊性、基本操作的內(nèi)聯(lián)化、訪問的直接性、堆棧的配置，還有對?#37325;載函數(shù)不會對語義造成不希望的修改?#30340;保證。
此外，如果默認(rèn)為virtual的話，你將需要一個non-virtual或final關(guān)鍵字，而且當(dāng)過度使用它時會導(dǎo)致擴(kuò)展性問題。在語言設(shè)計里，的確沒有免費(fèi)午餐。
Elden Nelson：在您看來，經(jīng)由IEEE執(zhí)行的標(biāo)準(zhǔn)化過程對C++語言的完備性、靈活性以及能力等方面產(chǎn)生了怎樣的影響？
Bjarne Stroustrup：對于C++來說，ISO標(biāo)準(zhǔn)化過去以和現(xiàn)在都是重要的。其重中之重在于，標(biāo)準(zhǔn)委員會為技術(shù)人員提供了一個探討技術(shù)問題的?#20013;立的舞臺?#12290;還有什么別的地方能夠讓來自于相互競爭的機(jī)構(gòu)（比如Microsoft、IBM、Borland/Inprise以及Sun等）的用戶和編譯器編寫者們出于對用戶利益著想，坐到一起合作共事呢？ISO的工作是民主的，是以大多數(shù)人的意見為基礎(chǔ)的。為了達(dá)成一致的意見是需要時間的，但這樣的努力非常值得。否則將導(dǎo)致語言的定義只為某一家公司（或少數(shù)幾家公司）的利益服務(wù)。
由ISO工作而形成的標(biāo)準(zhǔn)C++比以前任何版本的C++都更加接近我的理想。標(biāo)準(zhǔn)C++的?#24322;常?#19982;我自己定義的幾乎相同，模板更具靈活性，名字空間和運(yùn)行時類型信息也被添加進(jìn)來。從對編程風(fēng)格（你也可稱之為?#33539;型?#65289;提供支持的角度來看，其余內(nèi)容皆屬于細(xì)節(jié)問題，自然而然，標(biāo)準(zhǔn)委員會工作的主要部分便是精確定義這些細(xì)節(jié)。
鑒于接近標(biāo)準(zhǔn)的編譯器可以廣泛獲得，人們試驗(yàn)?zāi)切┬鹿δ艿臅r機(jī)已經(jīng)來臨。在幾年之前很多東西還沒有成為現(xiàn)實(shí)，如今可以在實(shí)際應(yīng)用中使用它們了。那些對于大多數(shù)人來說僅能在語言定義上看到的技術(shù)，現(xiàn)在已被開發(fā)出來。例如STL（標(biāo)準(zhǔn)庫中容器和算法的框架）就是一個有意思的新技術(shù)的優(yōu)秀資源。
當(dāng)然了，在接下來的關(guān)鍵項(xiàng)目中，你不應(yīng)該沖到最前面使用所有語言特性和所有新技術(shù)，但是，是開始學(xué)習(xí)新語言特性和新標(biāo)準(zhǔn)庫并試驗(yàn)它們哪些適合你哪些不適合你的時候了。
假如需要文檔資料，你可以通過ANSI以18美元購得C++標(biāo)準(zhǔn)（參見
www.research.att.com/~bs/C++.html），也可以免費(fèi)獲得接近標(biāo)準(zhǔn)的草案。但是，這份標(biāo)準(zhǔn)并不是教本。我向有一定經(jīng)驗(yàn)的程序員推薦我的《The C++ Programming Language》第三版，這本書以更易理解的方式講述了完整的語言和標(biāo)準(zhǔn)庫，它還闡明了C++支持的很多基本設(shè)計和編程技術(shù)。然而，即便這本書也不適合初學(xué)者閱讀，因此，請先瀏覽我的個人主頁（www.research.att.com/~bs/）以了解我的寫作風(fēng)格和詳細(xì)程度能否滿足你的需要。
Elden Nelson：在不少流行領(lǐng)域，C++正漸漸失去光芒，因?yàn)樗笕藗兓ê艽蟮木θΩ兑恍┖芑镜墓ぷ鳎热绻芾韮?nèi)存（因?yàn)闆]有垃圾回收機(jī)制），管理模塊之間的依賴性（因?yàn)闊o法創(chuàng)建包（packages）），管理組件的版本。C++缺乏一些現(xiàn)代語言已經(jīng)視為標(biāo)準(zhǔn)的特性，謠傳中最酷的Java語言試圖解決這些問題，那么解決這些問題是否會導(dǎo)致C++的發(fā)展背離其根本宗旨呢？C++應(yīng)該怎樣發(fā)展以保證我們在這種語言上的投資能有合理的回報，而不是被迫從頭學(xué)用另一種語言？
Bjarne Stroustrup：我倒還沒有注意到C++比以前用的少了，相反，我看到的指標(biāo)表明C+的使用還在穩(wěn)步上升。只不過這種基數(shù)很大的穩(wěn)定增長以及在標(biāo)準(zhǔn)性、移植性和庫方面的不斷提高并沒有造成什么具有欺騙性的新聞效應(yīng)而已。我認(rèn)為你所說的?#22833;去光芒?#21482;不過是市場營銷和新聞意義上的現(xiàn)象。
如果你需要垃圾回收機(jī)制的話，你可以在C++應(yīng)用程序中插入一個垃圾回收器。有不少免費(fèi)的和商業(yè)的垃圾回收器已經(jīng)在重要的實(shí)踐中被證明非常出色（可以參見www.research.att.com/~bs/C++.html）。
如果你不想使用垃圾回收機(jī)制也沒關(guān)系，你可以使用標(biāo)準(zhǔn)容器類，它們大大減少了對于顯式分配和回收內(nèi)存的需要。這樣，通過使用現(xiàn)代的庫所支持的現(xiàn)代的編程風(fēng)格，你就能避免絕大多數(shù)內(nèi)存管理問題。
同樣的技術(shù)還可以用來避免一般資源的管理問題。并不是只有內(nèi)存才會泄漏，線程句柄、文件、互斥鎖、網(wǎng)絡(luò)連接等都是重要的資源，為了建立可靠的系統(tǒng)，它們必須被正確地管理。如果你以為有了自動垃圾回收機(jī)制就可以解決所有資源管理問題，那你最好趕快從美夢中醒來。
C++提供了一些機(jī)制來管理常見資源。關(guān)鍵的手段 ?資源獲取即初始化（resource acquisition is initialization）依賴于函數(shù)對象來管理生存期問題。語言中關(guān)于對象的部分構(gòu)造（partial construction of objects）規(guī)則和異常機(jī)制對這項(xiàng)技術(shù)提供了一般性的支持。關(guān)于異常處理技術(shù)的討論，請參閱The C++ Programming Language (Special Edition) 的新附錄揝tandard-Library Exception Safety?#65292;它也可以從我的Web站點(diǎn)訪問到(www.research.att.com/~bs/3rd_safe0.html)。
某些語言的狂熱支持者總是用諷刺的手法來描述C++，然而C++實(shí)際上要好得多。特別是我認(rèn)為很多其他特性已經(jīng)被吹噓過度了，而在C++中，通常這些特性能夠很容易地被模擬出來。相反，新語言總有一種?#22312;損害一般性的情況下?#28155;加新特性的傾向，這也是一門新語言從誕生到被接受為一種用于常見計算的有用的工具，其體積和復(fù)雜度通常會增加兩到三倍的原因之一。
目前，使用C++的個人和組織可以進(jìn)行的最佳投資就是去更好地理解標(biāo)準(zhǔn)C++和現(xiàn)代的C++設(shè)計和編程技術(shù)。大多數(shù)人使用C++的方式實(shí)際上停留在80年代中期的水平，甚至比那更落后。
精確區(qū)分語言和系統(tǒng)/平臺之間的責(zé)任是一個困難的問題，我的觀點(diǎn)是，它們之間應(yīng)該有一個明顯的分界線，并且，依賴關(guān)系應(yīng)該盡可能地置身于語言之外，系統(tǒng)相關(guān)（system-specific）和系統(tǒng)依賴（system-dependent）的庫才是解決系統(tǒng)依賴性的地方，而語言并不是。
我不認(rèn)為組件版本管理之類的問題應(yīng)該由編程語言來解決，這是一個系統(tǒng)范疇的問題，在語言里應(yīng)該通過提供用于系統(tǒng)訪問的適當(dāng)?shù)膸靵斫鉀Q。C++有這樣的機(jī)制。解決這樣的問題并不會違背我對C++所奉行的理念。但在另一方面，給C++增加很多特殊的特性會使C++偏離軌道，而且在保持可移植性和平臺獨(dú)立性方面也是一個倒退。
Elden Nelson：如果為庫中某個基類定義一個派生類，要想覆寫（override）基類的一個虛函數(shù)，你就必須得到這個基類的源代碼，以便獲知是否需要調(diào)用基類中該函數(shù)的實(shí)現(xiàn)代碼，您是否認(rèn)為C++類庫在這方面有那么一些失敗？
Bjarne Stroustrup：唉，造成某些C++類庫的這種缺陷的原因是，其設(shè)計者認(rèn)為必須將此問題定義到他們的庫中，并且一些用戶認(rèn)為他們必須以這種方式來使用庫。這真是差勁的設(shè)計，是對C++差勁的使用！
如果你不想依賴基類的數(shù)據(jù)或者代碼，就不要把它們放到基類中，這正是抽象類的使命。考慮如下代碼：
class Reader {
public:
virtual bool empty() = 0;
virtual Element get() = 0;
};
它為所有派生類提供了揜eader?#21151;能的一個接口。Reader的用戶完全不依賴于那些派生類的實(shí)現(xiàn)細(xì)節(jié)。尤其是當(dāng)某個派生類的代碼改動時客戶代碼并不需要重新編譯。還有，用戶可以同時使用Reader類的多種不同實(shí)現(xiàn)（也就是說，可以同時使用多個不同的派生自Reader的類）。
從1989年發(fā)布的2.0版起，抽象類就已被直接支持，并且這項(xiàng)技術(shù)/風(fēng)格總是隨時可用的。這些歷史以及語言設(shè)計考慮在《D&E》中皆有描述，自然而然，The C++ Programming Language解釋了在什么情況下以及該怎么使用抽象類。
隨便說一句，通過繼承一個抽象接口類，再繼承某個類層次結(jié)構(gòu)中一個具體類（以獲得它提供的有用功能的實(shí)現(xiàn)代碼），是多重繼承的一個最簡單、最明顯
的用法：
class My_class : public Interface, protected Implementation {
// override virtual functions from Interface,
// implementing the overriding functions
// using facilities offered by Implementation
// Where needed, also override virtual functions
// from Implementation
}
我認(rèn)為抽象類是一項(xiàng)遠(yuǎn)遠(yuǎn)沒被充分利用的C++特性。程序員總是設(shè)計層次深深的繼承體系，還在基類中添加大量數(shù)據(jù)和代碼。有時這么做是有道理的，但在大的系統(tǒng)接口設(shè)計中，你更需要的是程序不同部分間的獨(dú)立性，由抽象類提供的純粹的接口往往便是更好的設(shè)計選擇。較老的C++庫的另一個問題在于，其設(shè)計者還不能使用模板。有些情況下繼承的使用毫無必要或緣于無知，因?yàn)閷㈩愋蛥?shù)化更加合適。
Elden Nelson：為什么在C++中沒有關(guān)鍵詞搒uper?#65311;
Bjarne Stroustrup：因?yàn)樵贑++中，它既非?#24517;要?#20063;不?#20805;分?#12290;
搒uper?#20043;所以不必要，是因?yàn)锽ase::f這種符號允許程序員表達(dá)f是揃ase的一個member?#25110;是揃ase的一個base?#12290;
搒uper?#20043;所以不?#20805;分?#65292;是因?yàn)槟阈枰磉_(dá)f來源于Base1而非Base2。
Elden Nelson：一些廠商已經(jīng)或正在對他們的C++編譯器進(jìn)行修改，以支持平臺相關(guān)的語言擴(kuò)展。您對此有什么看法，您認(rèn)為這會有什么作用？
Bjarne Stroustrup：我認(rèn)為平臺相關(guān)的語言擴(kuò)展應(yīng)該最小化，當(dāng)必須進(jìn)行擴(kuò)展時，其設(shè)計應(yīng)該局部化于庫中。當(dāng)然，比起我自己，平臺供應(yīng)商們傾向于認(rèn)為要進(jìn)行更多必不可少的擴(kuò)展。他們還傾向于使擴(kuò)展彌漫于應(yīng)用代碼之中，從而使用戶很難更換供應(yīng)商。身為一個注重可移植性的用戶，我對這種套牢用戶的伎倆表示遺憾。
出于用戶的利益著想，理想狀態(tài)必須是可移植的，且平臺相關(guān)的代碼應(yīng)被隔離在應(yīng)用代碼的一些特別段落。可移植性，以及不因廠商的奇思異想而改變的語義，是一門標(biāo)準(zhǔn)語言比專有語言優(yōu)越之處。我認(rèn)為C++供應(yīng)商們應(yīng)該意識到這可以成為一個競爭優(yōu)勢，并將專有擴(kuò)展及擴(kuò)展所引起的沖擊最小化。假如你想用Java和Visual Basic那樣的專有語言，你知道到哪兒去找它們。
Elden Nelson：您對目前花色繁多的C++編譯器有什么看法？請不要因?yàn)檫@是《Visual C++ Developers Journal》的采訪而影響您的看法。
Bjarne Stroustrup：它們正變得越來越好。這包括所有C++編譯器。我通常使用六種不同的C++編譯器。幾年前我是做不到這一點(diǎn)的，當(dāng)時一些被廣泛使用的C++編譯器還不能完全滿足我的需要。
我樂意讓?#36825;是《Visual C++ Developers Journal》的采訪?#30340;事實(shí)影響我要說的話。因?yàn)檫@正是鼓勵微軟更加
遵循標(biāo)準(zhǔn)的絕佳場合！VC++已得到改進(jìn)，但是憑微軟所擁有的資源，還可以進(jìn)一步提高符合標(biāo)準(zhǔn)的程度，并為核心語言特性和標(biāo)準(zhǔn)庫提供更高質(zhì)量的支持。例如，對于目前大多數(shù)C++編譯器來說，關(guān)于模板的出錯提示信息仍有較大改進(jìn)余地。
在
遵循標(biāo)準(zhǔn)方面，現(xiàn)在的情況比以前要好多了，但在VC++中，我們?nèi)匀徊荒苁褂媚０逵言╰emplate friends）和模板部分特化（partial specialization）功能。我非常樂意看到有人實(shí)現(xiàn)了對模板的分別編譯（separate compilation） ?從Cfront時代起，它就是一項(xiàng)我想用而無法用的重要功能。
如果VC++能為新手學(xué)用標(biāo)準(zhǔn)功能打開方面之門，那將是一件好事。下邊是那個沒什么實(shí)際價值的?#31532;一個?#31243;序：
#include<iostream>
int main()
{
std::cout << "Hello,
new world\n";
}
在我看來，略微提高投在標(biāo)準(zhǔn)庫方面的資源，而不是提高投在專有擴(kuò)展和專有功能方面的資源，將是微軟幫助最大數(shù)量的程序員最廉價的方法。
通常產(chǎn)生的代碼的性能挺好。基于用戶社群不同的關(guān)注方面，各種編譯器傾向于各有區(qū)別。我認(rèn)為最重大的收益來源于對標(biāo)準(zhǔn)庫的調(diào)整。例如，從一個istream中將一個字符序列讀入一個string，就是一個值得優(yōu)化的操作，不為別的，它可以避免程序員去擺弄諸如字符讀取、顯式緩沖、空間分配和指針之類的玩藝。舉個例子，下面的代碼既優(yōu)雅又不失效率：
vector<string> vs;
string terminator = "endend";
string s;
while (my_input>>s && s!=terminator) vs.push_back(s);
請參閱我寫的《把標(biāo)準(zhǔn)C++當(dāng)作一門新語言來學(xué)習(xí)》一文中關(guān)于風(fēng)格和效率的議題（我的損ublications?#39029;面有鏈接）。
Elden Nelson：標(biāo)準(zhǔn)C++并沒有任何方式定義支持并發(fā)（concurrency）、持久化（persistence）和基于組件的編程（component-based programming），這導(dǎo)致了互不兼容的、平臺相關(guān)的框架（例如CORBA、DCOM和SOM等）的繁殖，所有這些都有違直覺、雜亂無章，這不正表明標(biāo)準(zhǔn)C++應(yīng)該為并發(fā)（尤其是線程）和組件對象模型提供直接支持嗎？
Bjarne Stroustrup：?#24182;發(fā)?#21644;?#32452;件對象模型?#26080;疑是擺在當(dāng)今所有語言的設(shè)計者面前的巨大挑戰(zhàn)。不幸的是，這些挑戰(zhàn)往往出于政治原因而非技術(shù)因素，有太多的金錢使之走樣。
用戶的理想語言應(yīng)該是一門直接支持廣泛的并發(fā)需求并對組件這一通用概念提供良好支持的語言。在理想狀態(tài)下，程序員