------專訪C++之父Bjarne Stroustrup博士------ 《C++程序設計語言（特別版）》試讀 感謝C++ View讓我們轉載它的這篇專訪（2000-2002 C-View.ORG All Rights Reserved），未得C++ View同意，任何人請勿將此文再做轉載。采訪：蟲蟲，翻譯：ALNG Bjarne Stroustrup博士，C++語言的設計者和最初實現者，現任AT＆T實驗室的大型程序設計研究部的主管。著有《C++程序設計語言》(1985年第1版，1991年第2版，1997年第3版，2000年特別版)、《The Annotated C++ Reference Manual》和《C++語言的設計與演化》。Bjarne于1950年生于丹麥美麗的港口城市奧爾胡斯市，在奧爾胡斯大學取得碩士學位，在英國著名的劍橋大學完成了他的博士學業......更多>>> 專訪索引 1、C++的標準化進程 2、C++的模板函數 3、經典流 4、C++、Java與C# 5、Bjarne看C++的機制 6、STL與C++的GUI 7、在C++中相得益彰的GP和OO 8、今后C++將支持分布開發 9、愛好廣泛的Bjarne 10、Bjarne的中國觀 1、C++的標準化進程 　　　　　　　　　　　　　　　　　　　　　　　　　　　　TOP 記者：C++的ANSI/ISO標準化標志著C++的成熟。能告訴我們在這個標準化的過程中，您感到最難忘、最快樂以及最遺憾的事分別是什么嗎？ Bjarne Stroustrup：標準化進程其實是一項極具價值的重大活動，但是人們對它認識太不足了，而且整個進程也是荊棘滿途。實際上，通過標準化活動，C++語言顯得越發成熟和完善了，還因此而獲得了有著驚人表達能力的標準庫。編譯器的廠商老想束縛住他們的用戶，而正式的標準化活動，則是用戶們為數不多的自衛手段之一。 　　很難說哪一件事是最特別的。在委員會中，大多數的工作都是發現、提煉和建立信任的這樣一個過程，這都需要花費大量的時間。不過最重要的事莫過于以下兩件事，其一是1990年基于《The C++ Programming Language》第2版的參考手冊（有模板和異常處理機制的那一版）進行C++標準化的那第一次的投票，其二則是1998年批準ISO標準的最終表決。毋庸置疑，在這兩件大事當中，將STL接納為標準庫一部分的投票是一件最令人歡欣鼓舞的快事。 　　可以說，沒有任何負面或者遺憾的事情能與這些具有進步意義的投票相提并論。說到"遺憾"，要么是一些十分微小的技術細節，要么就是那些（暫時）分化了委員會而使進展緩慢的討論。例如，我本來是反對C風格的強制類型轉換，也不想引入僅允許整型的靜態常量成員在類中初始化的機制。不過，這都是些無關痛癢的小節。 　　我正期待著另外一次關鍵的表決。明年（2002年）的某個時候，委員會將決定ISO C++的未來方向，這可是頭等大事啊！ 2、C++的模板函數 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　TOP 記者：Alexander Stepanov說有一次他曾經與你爭論。因為他認為C++的模板函數應該像Ada通用類一樣顯式實例化，而你堅持認為函數應使用重載機制隱式實例化。正是由于您的堅持，這一技術后來在STL中發揮了重要作用。能跟我們具體談談嗎？ Bjarne Stroustrup：對此，我已經沒有多少可補充的了。在模板成為C++的一部分之前，Alex和我曾經花了一些時間去討論語言特性。從我的角度來看，當時的Ada經驗給他施加了過大的影響，而Alex有著自己的優勢--泛型編程的寶貴實踐經驗，這恰恰是我的不足。他強化了我對不犧牲效率和內限制表達能力或犧牲效率的實現方法。尤其是過去我對能否把模板參數限制在繼承層次持懷疑態度，如今我態度依然。聯的偏好。我們都討厭宏而喜歡類型安全。他本來想要更強的模板參數的靜態類型檢驗，我也是這么想的，不過還沒有找到可以不 　　后來Alex創造性地使用了我所設計的模板特性，這就導致了STL的誕生，使得目前人們開始重視泛型及生成編程。跟Alex爭論很有意思！關于我對他風格的印象，參看http://www.stlport.org/resources/StepanovUSA.html【記者注：這是一篇STL之父Alexander Stepanov的訪談錄，內容相當激進，心臟不好的人請做好一切必要準備^_^。Alex在GP上有極深的造詣，這篇訪談顛覆性不小，甚至可以看到他對OO的批判！也許徹底拋棄OO很難，但Alex的話確實富有啟發性，值得一看】。 　　我曾經試驗過多種在不使用語言擴展的情況下約束模板參數的方式。個人早期的想法在《The Design and Evolution of C++》（《C++語言的設計與演化》的中文版和影印版均已由機械工業出版社引進出版）一書中已有詳述，其后期的變體如今成為了普遍使用的約束和概念檢查的一部分。這些系統在表現力和彈性上比在其他語言中的常見內建設施要強很多。如果要舉例的話，可以參閱我的C++ Style and Technique FAQ（http://www.research.att.com/~bs/bs_faq2.html#constraints）。 3、經典流 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　TOP 記者：Jerry Schwarz在Standard C++ IOStream and Locales一書的前言中回顧了IOStream的歷史。我想在從經典流到標準IOStream的轉變過程間一定有很多趣事，您能給我們講一些呢？ Bjarne Stroustrup：我不想替這次轉變再多說些什么了。然而，我想強調的是原來我所設計的流庫簡單且高效，我在兩個月內就完成了設計和建構。 　　那次關鍵的決策把格式與緩沖分離開來，并使用了類型安全的表愛貓撲.愛生活于<<和>>運算符）。與AT&T貝爾實驗室的同事Doug McIlroy進行了一番探討之后，我最終做出了這些決策。實驗表明，諸如<、>、逗號和=都不太合適，后來我選擇了使?lt;<和>>。類型安全使得在編譯時就可以決定一些原本在C風格庫中需要在運行時才決定的事情，因而其性能非同一般。在我剛開始使用流以后的不久，Dave Presotto就把我的實現的緩沖部分替換成一個更出色的部分，我一直都沒有注意到這一點，直到他后來告訴我。 　　目前的IO流肯定小不了。不過我堅信，在許多通常沒有使用IO流全部通用性的情況下，借助于強力的優化，我們可以重獲原來的效率。注意，IO流之所以如此復雜，大部分的原因是為了滿足那些我原來所設計的經典流沒能考慮到的需求。例如，帶本地化的標準IO流就可以處理經典流力不能及的漢字和漢字串。 4、C++、Java與C#　　　　　　　　　　　　　　　　　　　　　　　　　　　　　TOP 記者：有人說Java是純粹面向對象的，而C#更勝一籌。而還有很多人說它們純粹是面向金錢的。以您之見呢？ Bjarne Stroustrup：我喜歡"面向金錢"這個詞 :-) 還有Andrew Koenig的成語"面向大話"我也喜歡。 不過，C++可不面向這兩個東東。 　　對這點我還想指出，我認為純粹性并不是優點。C++的強項恰恰在于它支持多種有效的編程風格（多種的思維模型，如果你一定要這么說）以及他們之間的相互組合。最優雅、最有效也最容易維護的解決方案常常涉及不止一種的風格（編程模型）。如果一定要用吸引人的字眼，可以這么說，C++是一種多思維模型的語言。在軟件開發的龐大領域之中，需求千變萬化，需要至少一種支持多種編程風格的通用語言，而且很可能需要一種以上。再說，世界之大，總能容得下好幾種編程語言吧？那種認為一種語言對所有應用和每個程序員都是最好的看法，本質上就是荒謬的。【注：paradigm的中文翻譯似乎沒有約定。有人偏好"典范"或者"范式"，記者則喜歡侯捷先生使用的"思維模式"或者"思維模型"。總之，paradigm的大概意思是an example or pattern，大家理解就行。】 　　Java和C#的主要力量源自于其所有者的支持。這意味著低價（為取得市場份額免費發放實現和庫），集約和不擇手段的營銷（欺騙宣傳），以及由于缺乏替代廠商而產生的表面上的標準。當然，就Java的情形而言，當其他廠商和修改版本出現后，版本、兼容性和移植問題也會像其他語言一樣，重新冒出來。 　　不被語言所有者操縱的開放進程所產生的正式標準是最好的。如果用戶不想看到這種語言為了其發起者或所謂"一般用戶"的利益，而不顧經濟上無足輕重的"少數派"反對而來回折騰，像ISO這樣正式的標準進程，則是他們唯一的希望了。 　　C++本可以更簡單或更易用些（更純粹，如果你認為這是必要的），不過這樣就無法支持那些有著"不同尋常"的需求的用戶了。我個人很關注他們，他們要構建可靠性、運行效率以及可維護性遠高于行業平均水準的系統。我的猜測是，在10年內大多數的程序員都將面臨"不同尋常"的技術要求，他們可以從C++的多思維模型結構中受益，而Java和C#之類"簡化"語言則力有不逮了。 　　我認為模板和泛型編程是現代C++的核心，是無損效率、類型安全代碼的關鍵。然而它們并不適合經典的面向對象編程思維模型。 5、Bjarne看C++的機制 　　　　　　　　　　　　　　　　　　　　　　　　　　TOP 記者：Ian Joyner在C++： A Critique of C++ and Programming and Language Trends of the 1990s一書中比較了C++和Java并批評了C++的許多機制。你贊成他的觀點嗎？尤其是多數新語言都有垃圾收集機制，C++中會加入嗎？ Bjarne Stroustrup：Ian Joyner對C++的觀點，我不敢茍同。撇開這點，垃圾收集可能算是有價值的技術，不過并不是萬能丹，它也會帶來問題。對C++而言，自動垃圾收集是一個有效的實施技術，有許多為C++設計的不錯的垃圾收集器（商業支持和免費的都有），而且也被廣泛地使用（參看我的C++頁面上的鏈接）。然而C++中垃圾收集機制應該是可選的，這樣在不適合垃圾收集的地方，如嚴格的實時應用程序，可以免受其累。關于垃圾收集，我的《The C++ Programming Language》（《C++程序設計語言》）一書和我的主頁上都用評注，可以參看。 　　我期望在下一個C++標準中能體現出我的意見，并做出明確的聲明。就此而論，C++可以優雅地處理一般的資源，而不僅僅局限于內存。尤其是"resource acquisition is initialization（資源獲得就是初始化）"技術（參看D&E、TC++PL和我的技術FAQ）支持對任意資源進行簡單并且符合異常安全（exception-safe）要求的管理。沒有析構函數的Java不可能支持這一技術。 6、STL與C++的GUI 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　TOP 記者：STL是一個超凡脫俗的跨平臺架構。有沒有考慮在其他方面，比如GUI（圖形用戶接口），設計這樣的標準架構？ Bjarne Stroustrup：很自然地，很多人會想如何在其他領域借鑒STL的成功。比如在數值運算和圖論方面都有了許多有趣的工作。相關鏈接可以參看我的網頁。 　　標準GUI價值極大，不過我懷疑其政治上的可行性。太多有錢的大公司在維持其專有GUI上有著重大的商業利益，而且要求用戶放棄現在所使用的GUI庫也殊非易事。【注：有朋友可能奇怪，一個GUI庫怎么扯出"政治（politically）"來了？西方人口中的"政治"，在中文里并沒有真正對應的詞語。這里的意思是of concerning public affairs，跟中文里的"政治"無關。下一段就是對這個所謂"政治上的可行性"的詳細解釋。】 　　這里我所說的可行性是就商業和技術而言。現在有好幾種廣泛使用的GUI，即使標準委員會提供一個替代方案，它們也不會就此退出。其所有者和用戶──常常有充分理由──會只是忽略新標準。更糟的情況：某些公司或群體會積極反對這樣的標準，因為他們認為標準不如他們已有的庫，或者因為差異太大而使得轉換到新GUI不可行。必須理解，如果標準不能充分服務于其目標用戶，用戶會視而不見。許多ISO標準因為無人理會而變得無關緊要。C++標準可不想成為其中一員──把現有實施拉近到一起，標準就功德無量了──我們不希望將來ISO C++標準被人忽略。 　　注意STL成功的一個主要原因在于它是一個技術突破。它可不單是"又一個容器庫"，因此它不需要和許多現有的容器庫（其中幾個品質卓著）直接競爭。我猜想C++要有一個標準GUI，我們需要技術突破，加上好運多多。 　　不過我還是懷疑委員會有由必需的專業技術和資源來構建一個可以成為真實世界中真正標準的GUI。 　　我對標準庫的想法傾向于修補現有庫的遺漏（如hash_map和正則表達式），以及通過更廣泛的運行時間類型信息和并發庫來支持分布運算（可選）。 　　有時大家忘了，庫不是非得成為標準的一部分才有用。有成千上萬有用的C++庫。例如，參見C++庫FAQ（我的C++網頁有鏈接）。 7、在C++中相得益彰的GP和OO　　　　　　　　　　　　　　　　　　　　　　　　　　TOP 記者：泛型編程是C++特殊的編程思維模型。你是怎樣看GP（泛型編程）和OO（面向對象）的？將來C++會提供更強大的機制來支持GP嗎？有沒有考慮引入其他思維模型，比如面向模式？ Bjarne Stroustrup：我認為，在C++中面向對象和泛型編程相得益彰，我所寫的許多最優美的代碼段都是兩者的結合。也就是說，那些認為OOP和GP水火不容的觀點是錯誤的。它們是應該組合使用的技巧，語言應該支持這樣的組合──C++正是如此。 　　我覺得C++相當好地支持了泛型編程，所以只需要細微的增加。模板化的typedef是個顯而易見的例子。我們要謹慎地擴展語言，僅當擴展對要表述的內容提供重大的便利時，我們才這樣做。比如我不支持對模板參數約束檢查提供直接語言支持的想法。通過約束／概念檢查模板，我們已經可以比用為C++和相似的語言提議的各種各樣的語言擴展做得更多。 　　談起"思維模型"和"新的思維模型"讓我很為難，只有很少的想法佩得上這樣美妙的字眼。我也擔心對新觀念過于直接的支持，可能會限制和跟不上我們的觀念和技術的進一步演化。理想的情況是，語言設施應有效地支持非常通用的觀念，這樣大家可以使用這些設施用各種風格來編寫代碼。至于C++能優雅地支持哪些模式概念，能和不能通過與已有風格的組合，還有待觀察。我認為，只需要很少新的特定語言概念來支持模式。 8、今后C++將支持分布開發 　　　　　　　　　　　　　　　　　　　　　　　　　　TOP 記者：今后C++會支持分布開發嗎？對RTTI和多線程的進一步支持呢？ Bjarne Stroustrup：對。如果事情進展能如我所愿，C++標準的下一次修訂會通過提供擴展的類型信息和并發支持庫來支持分布計算。我覺得這不需要特別的語言擴展。不過在存在并發的情況下現有語言設施實施需要做出額外的保證。 　　我沒有太多可說，因為圍繞下一標準應該和不該包含哪些的討論才剛剛開始。我的看法是C++需要一個無縫地支持線程（在同一地址空間內）、進程（在不同地址空間）及遠端進程（可能有重大的通訊延時而且網絡可能暫時分離）的標準庫。支持這點會需要超越簡單的Unix或Windows線程的設施。但是我并不認為這需要設計新的語言元件。 9、愛好廣泛的Bjarne 　　　　　　　　　　　　　　　　　　　　　　　　　　　　TOP 記者：據說大人物年輕時就會表現出與常人的差異，請問您在大學就讀時表現過什么與眾不同的地方？ Bjarne Stroustrup：我并不清楚是否有人覺得我真的與眾不同。我猜想自己可能比多數人天真和顯得理想主義那么一點點。此外，比起大多數人，我花在解決現實問題的時間會多一點吧──我要掙錢以免債臺高筑。我可不能如此，因為家里并不富有，我一直被告誡要勤奮工作。另一方面，我喜歡學習自己感興趣的許多東西（包括哲學和歷史），而不僅僅是那些直接有助于我取得學位和提高成績的東西。 10、Bjarne的中國觀 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　TOP 記者：喜歡安徒生的童話嗎？在《夜鶯》里他寫到了中國。您對中國、中華文化和中國人的印象如何？以前去過中國嗎？2008年來中國看奧運會可能是個不錯的主意。 Bjarne Stroustrup：作為一名丹麥人，我當然知道安徒生童話。恰好我也很喜歡這些故事。在《夜鶯》里描繪的中國純屬虛構，與當時的中國可能有也可能沒有任何聯系。安徒生創造的那個"中國"，是用來泛指許多個國家及其統治者的。 　　中國是個巨大的概念Bjarne Stroustrup，很難能對之有一個總體的印象。我所遇到的中國人大都是程序員或者工程師，因此我對中國人的看法可能會過于狹隘。縱使是類似于我的本國丹麥這樣的小國和文化體也是十分復雜的，不是單個人能夠完全理解的──丹麥只有500萬人口。我對歷史很感興趣，因此也看了數本有關中國歷史和文化題材的書籍。不過這可能意味著我頭腦里的中國會比較古老，與現在的中國并不能相提并論。我在臺灣進行過一個星期的講學，那里挺不錯的，不過目前我尚沒有機會訪問大陸。 　　關于中國歷史和文化的書我看過不少。中國歷史悠久、幅員遼闊，因此書的內容就集中于早期的事件、人和傳統，幾乎沒有描繪近10年或者20年的中國。盡管從新聞和中國朋友那里得知中國已經發生了巨大的變化，但是我對今日的中國還是相當無知（但是可能比大多數人對遠方國度的那種無知要強一些），比如我對當今中國的文學和音樂一無所知。因而一旦想起中國，我就可能想起很多嚴重過時的東西──盡管自己極力去避免此類的錯誤。這里順便說一句，我對主要從書本上獲知的世界其他地區也都有類似的問題。 　　我對大型人群和有組織的群體事件不太熱心，因此我會遠離2008年奧運會，就象我遠離那些原本可以參與的各屆奧運會一樣。我希望能找個除此之外的機會訪問中國。 Bjarne著作參考 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　TOP 《C++語言的設計和演化》 《C++語言的設計和演化（英文版）》 《C++程序設計語言（特別版）》即將出版，試讀、預訂 《C++ 程序設計語言（特別版）（英文影印版）》 --- 轉載-----