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