[譯者按] Bjarne Stroustrup博士，1950年出生于丹麥，先后畢業于丹麥阿魯斯大學和英國劍橋大學，AT&T大規模程序設計研究部門負責人， AT&T、貝爾實驗室和ACM成員。1979年，B. S開始開發一種語言，當時稱為“C with Class”，后來演化為C++。1998年，ANSI/ISO C++標準建立，同年，B. S推出了其經典著作The C++ Programming Language的第三版。C++的標準化標志著B. S博士傾20年心血的偉大構想終于實現。但是，計算技術的發展一日千里，就在幾年前人們還猜想C++最終將一統天下，然而隨著Internet的爆炸性增長，類似Java、C#等新的、現代感十足的語言咄咄逼人，各種Script語言更是如雨后春筍紛紛涌現。在這種情況下，人們不禁有些惶恐不安。C++是不是已經過時了呢？其前景如何？標準C++有怎樣的意義？應該如何學習？我們不妨看看B. S對這些問題的思考。以下文字是譯者從Stroustrup1998年之后發表的若干文章、談話筆記中精選出來的，由于出處不一，內容多有重復，為保持完整，亦一并譯出。
以下內容選自B. S在自己主頁上發表的FAQ
1. 請談談C++書。
沒有，也不可能有一本書對于所有人來說都是最好的。不過對于那些真正的程序員來說，如果他喜歡從“經典風格”的書中間學習一些新的概念和技術，我推薦我的 The C++ Programming Language, 1998年的第三版和特別版。那本書講的是純而又純的C++，完全獨立于平臺和庫（當然得講到標準庫）。該書面向那些有一定經驗的程序員，幫助他們掌握C ++，但不適合毫無經驗的初學者入門，也不適合那些臨時程序員品嘗C++快餐。所以這本書的重點在于概念和技術，而且在完整性和精確性上下了不少功夫。如果你想知道為什么C++會變成今天的模樣，我的另一本書The Design and Evolution of C++ 能給你滿意的答案。理解設計的原則和限制能幫助你寫出更好的程序。www.accu.com是最好的書評網站之一，很多有經驗的程序員在此仗義執言，不妨去看看。
2. 學習C++要花多長時間？
這要看你說的“學習”是什么意思了。如果你是一個Pascal程序員，你應該能很快地使你的C++水平達到與Pascal相近的程度；而如果你是一個C程序員，一天之內你就能學會使用C++進行更出色的C風格編程。另一方面，如果你想完全掌握C++的主要機制，例如數據抽象，面向對象編程，通用編程，面向對象設計等等，而此前又對這些東西不很熟悉的話，花上個一兩年是不足為奇的。那么是不是說這就是學習C++所需要的時間呢？也許再翻一番，我想打算成為更出色的設計師和程序員最起碼也要這么長的時間。如果學習一種新的語言不能使我們的工作和思想方式發生深刻的變革，那又何苦來哉？跟成為一個鋼琴家或者熟練掌握一門外語相比，學習一種新的、不同的語言和編程風格還算是簡單的。
3. 了解C是學習C++的先決條件嗎？
否！C++中與C相近的子集其實比C語言本身要好學，類型方面的錯誤會少一些，也不像C那樣繞圈子，還有更好的支持庫。所以應該從這個子集開始學習C++。
4. 要想成為真正的OO程序員，我是不是得先學習Smalltalk？
否。如果你想學Smalltaok，盡管去學。這種語言很有趣，而且學習新東西總是一個好主意。但是Smalltalk不是C++，而且把Smalltalk 的編程風格用在C++里不會有什么好結果。如果你想成為一個出色的C++程序員，而且也沒有幾個月的時間百無聊賴，請你集中力量學好C++以及其背后的思想。
5. 我如何開始學習C++？
這取決于你的基礎和學習動機。如果你是個初學者，我想你最好找個有經驗的程序員來幫助你，要不然你在學習和實踐中不可避免的犯下的種種錯誤會大大地打擊你的積極性。另外，即使你的編譯器配備了充足的文檔資料，一本C++書籍也永遠是必不可少的，畢竟文檔資料不是學習編程思想的好教材。
選擇書籍時，務必注意該書是不是從一開始就講授標準C++，并且矢志不渝地使用標準庫機制。例如，從輸入中讀取一個字符串應該是這樣的：
string s; // Standard C++ style
cin >> s;
而不是這樣的：
char s[MAX]; /* Standard C style */
scanf("%s",s);
去看看那些扎實的C++程序員們推薦的書吧。記住，沒有哪本書對所有人來說都是最好的。
另外，要寫地道的C++程序，而避免用C++的語法寫傳統風格的程序，新瓶裝舊酒沒多大意義。
（遺憾的是，目前在市面上的中文C++教材中，符合B. S的這個標準的可以說一本都沒有，大家只好到網上找一些英文的資料來學習了。——譯者）
6. 怎樣改進我的C++程序？
不好說。這取決于你是怎么使用該語言的。大多數人低估了抽象類和模板的價值，反過來卻肆無忌憚地使用造型機制(cast)和宏。這方面可以看看我的文章和書。抽象類和和模板的作用當然是提供一種方便的手段建構單根的類層次或者重用函數，但更重要的是，它們作為接口提供了簡潔的、邏輯性的服務表示機制。
7. 語言的選擇是不是很重要？
是，但也別指望奇跡。很多人似乎相信某一種語言能夠解決他們在系統開發中遇到的幾乎所有問題，他們不斷地去尋找完美的編程語言，然后一次次的失敗，一次次的沮喪。另外一些人則將編程語言貶為無關緊要的細節，把大把大把的銀子放在開發流程和設計方法上，他們永遠都在用著COBOL, C和一些專有語言。一種優秀的語言，例如C++，能幫助設計者和程序員做很多事情，而其能力和缺陷又能夠被清楚地了解和對待。
8. ANSI/ISO標準委員會是不是糟蹋了C++？
當然不是！他們（我們）的工作很出色。你可以在一些細節上找些歪理來挑刺，但我個人對于這種語言以及新的標準庫可是欣欣然。ISO C++較之C++的以前版本更出色更有條理。相對于標準化過程剛剛開始之初，你今天可以寫出更優雅、更易于維護的C++程序。新的標準庫也是一份真正的大禮。由于標準庫提供了strings, lists, vectors, maps以及作用于其上的基本算法，使用C++的方式已經發生了巨大的變化。
9. 你現在有沒有想刪除一些C++特性？
沒有，真的。問這些問題的人大概是希望我回答下面特性中的一個：多繼承、異常、模板和RTTI。但是沒有它們，C++就是不完整的。在過去的N年中，我已經反復考慮過它們的設計，并且與標準委員會一起改進了其細節，但是沒有一個能被去掉又不引起大地震。
從語言設計的角度講，我最不喜歡的部分是與C兼容的那個子集，但又不能把它去掉，因為那樣對于在現實世界里工作的程序員們來說傷害太大了。C++與C兼容，這是一項關鍵的設計決策，絕對不是一個叫賣的噱頭。兼容性的實現和維護是十分困難的，但確實使程序員們至今受益良多。但是現在，C++已經有了新的特性，程序員們可以從麻煩多多的C風格中解脫出來。例如，使用標準庫里的容器類，象vector, list, map, string等等，可以避免與底層的指針操作技巧混戰不休。
10. 如果不必和C兼容，你所創造的語言是不是就會是Java?
不是，差得遠。如果人們非要拿C++和Java來作比較，我建議他們去閱讀The Design and Evolution of C++，看看C++為什么是今天這個樣子，用我在設計C++時遵從的原則來檢驗這兩種語言。這些原則與SUN的Java開發小組所持的理念顯然是不同的。除了表面語法的相似性之外，C++與Java是截然不同的語言。在很多方面，Java更像Smalltalk（譯者按：我學習Java時用的是Sun的培訓教材，里面清楚地寫道：Java在設計上采用了與C++相似的語法，與Smalltalk相似的語義。所以可以說Java與C++是貌合神離，與 Smalltalk才是心有靈犀）。Java語言相對簡單，這部分是一種錯覺，部分是因為這種語言還不完整。隨著時間的推移，Java在體積和復雜程度上都會大大增長。在體積上它會增長兩到三倍，而且會出現一些實現相關的擴展或者庫。這是一條每個成功的商業語言都必須走過的發展之路。隨便分析一種你認為在很大范圍內取得了成功的語言，我知道肯定是無有例外者，而且實際上這非常有道理。
上邊這段話是在Java 1.1推出之前寫的。我確信Java需要類似模板的機制，并且需要增強對于固有類型的支持。簡單地說，就是為了基本的完整性也應該做這些工作。另外還需要做很多小的改動，大部分是擴展。1998年秋，我從James Gosling（Java語言的創始人——譯者）那里得到一份建議書，說是要在Java中增加固有類型、操作符重載以及數學計算支持。還有一篇論文，是數學分析領域的世界級大師，伯克利大學的W. Kahan教授所寫的How Java’s Floating-Point Hurts Everyone Everywhere（“且看Java的浮點運算如何危害了普天下的蕓蕓眾生”——譯者），揭露了Java的一些秘密。
我發現在電視和出版物中關于Java的鼓吹是不準確的，而且氣勢洶洶，讓人討厭。大肆叫囂凡是非Java的代碼都是垃圾，這是對程序員的侮辱；建議把所有的保留代碼都用Java重寫，這是喪心病狂，既不現實也不負責任。Sun和他的追隨者似乎覺得為了對付微軟罪惡的“帝國時代”，就必須如此自吹自擂。但是侮辱和欺詐只會把那些喜歡使用不同編程語言的程序員逼到微軟陣營里去。
Java并非平臺無關，它本身就是平臺。跟Windows一樣，它也是一個專有的商業平臺。也就是說，你可以為Windows/Intel編寫代碼，也可以為Java/JVM編寫代碼，在任何一種情況下，你都是在為一個屬于某個公司的平臺寫代碼，這些代碼都是與該公司的商業利益扯在一起的。當然你可以使用任何一種語言，結合操作系統的機制來編寫可供JVM執行的程序，但是JVM之類的東西是強烈地偏向于Java語言的。它一點也不像是通用的、公平的、語言中立的VM/OS。
私下里，我會堅持使用可移植的C++作大部分工作，用不同的語言作余下的工作。
（”Java is not platform-independent, it is the platform”，B. S的這句評語對于C++用戶有著很大的影響，譯者在國外的幾個新聞組里看到，有些C++高手甚至把這句話作為自己的簽名檔，以表明對Java的態度和誓死捍衛C++的決心。實際上有很多程序員不光是把自己喜愛的語言當成一種工具，更當成一種信仰。——譯者）
11. 您怎么看待C#語言？
就C#語言本身我沒什么好說的。想讓我相信這個世界還需要另外一個專有的語言可不是一件容易的事，而且這個語言還是專門針對某一個專有操作系統的，這就更讓我難以接受。直截了當地說，我不是一個專有語言的癡迷者，而是一個開放的正式標準的擁護者。
12. 在做大項目時，您是不是真的推薦Ada，而不是C++？
當然不是。我不知道這是誰傳出來的謠言，肯定是一個Ada信徒，要么是過分狂熱，要么是不懷好意。
13. 你愿不愿意將C++與別的語言比較？
抱歉，我不愿意。你可以在The Design and Evolution of C++的介紹性文字里找到原因。
有不少書評家邀請我把C++與其它的語言相比，我已經決定不做此類事情。在此我想重申一個我很久以來一直強調的觀點：語言之間的比較沒什么意義，更不公平。主流語言之間的合理比較要耗費很大的精力，多數人不會愿意付出這么大的代價。另外還需要在廣泛的應用領域有充分經驗，保持一種不偏不倚、客觀獨立的立場，有著公正無私的信念。我沒時間，而且作為C++的創造者，在公正無私這一點上我永遠不會獲得完全的信任。
人們試圖把各種語言拿來比較長短，有些現象我已經一次又一次地注意到，坦率地說我感到擔憂。作者們盡力表現的公正無私，但是最終都是無可救藥地偏向于某一種特定的應用程序，某一種特定的編程風格，或者某一種特定的程序員文化。更糟的是，當某一種語言明顯地比另一種語言更出名時，一些不易察覺的偷梁換柱就開始了：比較有名的語言中的缺陷被有意淡化，而且被拐彎抹角地加以掩飾；而同樣的缺陷在不那么出名的語言里就被描述為致命硬傷。類似的，有關比較出名的語言的技術資料經常更新，而不太出名的語言的技術資料往往是幾年以前的，試問這種比較有何公正性和意義可言？所以我對于C++之外的語言的評論嚴格限制在一般性的特別特定的范疇里。
換言之，我認為C++是大多數人開發大部分應用程序時的最佳選擇。
14. 別人可是經常拿他們的語言與C++比來比去，這讓你感到不自在了嗎？
當這些比較不完整或者出于商業目的時，我確實感覺不爽。那些散布最廣的比較性評論大多是由某種語言，比方說Z語言的擁護者發表的，其目的是為了證明Z比其它的語言好。由于C++被廣泛地使用，所以C++通常成了黑名單上的頭一個名字。通常，這類文章被夾在Z語言的供貨商提供的產品之中，成了其市場競爭的一個手段。令人震驚的是，相當多的此類評論引用那些在開發Z語言的公司中工作的雇員的文章，而這些經不起考驗文章無非是想證明Z是最好的。特別是在這些比較中確實有一些零零散散的事實，（所以更具欺騙性——譯者），畢竟沒有一種語言在任何情況下都是最好的。C++當然不完美，不過請注意，特意選擇出來的事實雖然好像正確，但有時是完全的誤導。
以后再看到語言比較方面的文章時，請留心是誰寫的，他的表述是不是以事實為依據，以公正為準繩，特別是評判的標準是不是對于所引述的每一種語言來說都公平合理。這可不容易做到。
15. 在做小項目時，C優于C++嗎？
我認為非也。除了由于缺乏好的C++編譯器而導致的問題之外，我從沒有看到哪個項目用C會比用C++更合適。
（不過現在C++編譯器導致的問題還是不可忽略的，當你看到同樣功能的C++程序可執行代碼體積比C大一倍而且速度慢得多時，會對此有所感觸的。——譯者）
以下內容來自Visual C++ Developer’s Journal主編Elden Nelson 2000年3月對B. S的專訪
16. 如果您現在有機會從頭設計C++語言，您會做些什么不同的事情？
當然，你永遠都不可能重新設計一種語言，那沒有意義，而且任何一種語言都是它那個時代的產物。如果讓我今天再設計一種語言，我仍然會綜合考慮邏輯的優美、效率、通用性、實現的復雜程度和人們的喜好。要知道人們的習慣對于他們的喜好有著巨大的影響。
現在，我會尋找一種簡單得多的語法，我會把類型系統的沖突問題限制在很少的幾種情況里，而且你能很容易的發現這些問題。這樣就能夠很容易的禁止不安全的操作。
（B. S的原則是：對于糟糕的代碼，就算是不能完全禁止，至少也要讓它大白于天下，而不是藏在陰暗的角落里暗箭傷人。C++實際上已經提供了這樣的機制，例如如果你使用象reinterpret_cast<int>(pointer)這樣的很明顯是非常糟糕的表達式進行造型，別人會很容易地找到問題所在。只不過C++仍然允許你使用傳統的、C風格的造型機制，而又有不少人一直使用這種老式的風格，所以才引來麻煩多多。B. S的意思是說，要是現在能夠禁止老式的風格該有多好！作為語言設計者的他，恐怕是沒有這個機會了，但是作為語言使用者的我們，卻還有很大的希望去改進自己的代碼。何去何從，應該是我們深思的時候了。——譯者）
我還會把核心語言的體積盡可能搞得小一些，包括類和模板的關鍵的抽象特性，而把很多其它的語言特性放在庫里來解決。當然我也會保證核心語言足夠的強大，使得那些庫本身也足以用這個核心語言來產生。我可不希望標準庫的創建需要用到什么不屬于該語言本身的神秘機制。另外我會讓這個核心語言的定義更加精確。（有不少新的語言在建庫時就使用了一些“不屬于該語言本身的神秘機制”，比如VB和JAVA。從理論上講，這是近乎無賴的行徑，所以B. S不以為然。不過從實用出發倒也無傷大雅。——譯者）
最重要的是，我會在該語言被廣泛使用之前盡可能維持一個很長的醞釀期，這樣我可以以其他人的反饋為基礎進行改進。這可能是最困難的，因為一旦有什么東西是明顯出色和有前途的，大家就會蜂擁而至的來使用它，此后作任何不兼容的修正都會是非常困難的。
我相信這些思想與我當初設計C++時的理念是非常類似的，同樣也是這些思想指引著一二十年來C++的不斷演化。當然，我認為現在還沒有什么東西能讓我覺得像是“完美的語言”。
17. 您預期C++做哪些增強，會不會刪掉一些東西？
很不幸，雖然有一些東西很應該扔掉，但恐怕很難真的刪掉任何東西。第一個應該拋棄的東西就是C風格的造型機制和強制類型轉換。就算不禁止，編譯器的作者們至少也應該對這種行為給與強烈的警告。我希望能用類似vector的東西徹底取代數組，但這顯然是不可能的。不過如果程序員們能主動使用vector來代替數組，就會立刻受益匪淺。關鍵是你不必再使用C++中最復雜難纏的技巧了，現在有優秀得多的替代方案。
至于主要的特性，我沒想去掉任何東西。特別是那些把C++與C區別開來的主要特性恐怕沒法風平浪靜的被拋掉。通常問這些問題的人是希望我挑出諸如多繼承、異常、模板等機制來接受批判。所以在這我想大聲講清楚，我認為多繼承機制對于靜態類型語言實現繼承性來說是必需的，異常機制是在大系統中對付錯誤的正確方法，模板機制是進行類型安全的、精致的和高效的程序設計的靈丹妙藥。我們可以在小的細節上對于這些機制挑挑刺，但在大的方面，這些基本的概念都必須堅持。
現在我們仍在學習標準C++，也正在標準所提供的特性基礎上發展出更新的、更有趣的編程技術。特別是人們剛剛開始使用STL和異常機制，還有很多高效強大的技術鮮為人知，所以大可不必急匆匆的跑去增加什么新的機制。
我認為當前的重點是提供很多新的、比以前更加精致的、更有用的庫，這方面潛力巨大。例如，如果有一個能被廣泛使用的、更精致的支持并發程序設計的庫，那將是一大福音——C風格的線程庫（例如Pthread——譯者）實在不夠好。我們也就可以與各種其他的系統，例如SQL以及不同的組件模型更好地契合起來。數值計算領域的人們在這方面好象已經走在了前面，類似像Blitz++、POOMA、MTL之類的高效而精致的庫的開發已經取得了非凡的成就。（譯者在 Internet上造訪了Blitz++和POOMA的主頁，前者是一個高性能數學庫，據稱其性能與Fortran 77不相上下，同時又支持大量的C++特性。我想凡是對于數值計算領域有所了解的人都知道這有多么偉大的意義。POOMA則是一個專門研究C++并行數學算法的項目，它的前景更加不可限量。譯者非常認同B. S的這個觀念。——譯者）
有了足夠的經驗之后，我們就能更好的決定應該對標準做些什么調整。
18. 顯然，這幾年世界變了，正在走向一個以Web為中心、分布式計算為主流的時代。那么您覺得C++還能維持其地位嗎？程序員們可不可能把若干種專用語言（比如Perl、Javascript）綜合運用以徹底取代某一種通用語言？（C++就是這樣的通用語言——譯者）為了配合新的計算模式，C++及其標準庫應該做怎樣的調整？
從來沒有哪一種語言能適合所有的工作，我恐怕以后也不會有。實際系統通常是用多種語言和工具構造起來的。C++只是想成為若干語言和工具中的一個，當某些專用語言在其領域里特別突出時，它們可以與C++互為補充。也就是說，我覺得如果大多數現在的專用語言能借助特定領域的C++庫共同工作的話，它們會表現得更出色。腳本語言通常導致難以維護的代碼，而且也沒有給程序的結構、可擴展性和可維護性的優化留下什么余地。
我不敢肯定未來的代碼是否真的會是以Web為中心的。就算是直接處理Web的系統也主要是由處理本地資源，如IP連接之類的程序模塊構成的。
地理上的分布性以及服務器軟件對于并發機制的高度依賴對于系統的建造者來說的確是個挑戰。有些針對上述問題的庫已經出現，也許我們將會看到它們最終得以標準化。當然，一些原操作和保證規則應該被加到核心語言中以提供對這些庫的更佳支持。
總的來說，對于Web和網絡，我們非常需要一個真正的系統/網絡級的安全模型。指望JavaScript之類的腳本語言實現這個模型無異于白日做夢。注意，我也沒說C++提供了這個問題的解決方式。C++的重心是高效的訪問系統資源，而不是反欺詐。
19. 您看C++未來的走向如何？在接下來的10年里它會衰落嗎？或者是基本保持現在的形式？或者發展變化呈不同的形式？
C++有著最美好的未來。用它你能寫出偉大的代碼。除了故意進行惡意欺詐，C++仍將是開發高性能、高復雜度系統的最好語言。據我所知，沒有那種語言能在通用性、效率和精致三方面的統一上可與C++相題并論。
我沒看到C++有衰落的征兆。在我能預見的未來里，它的用途還會不斷增長。當然，在未來的十年里我們會看到一些變化，但不會像你想得那么顯著。跟每一種語言一樣，C++也會發展變化。“語言專家們”要求改進的喧囂聲震耳欲聾，但是系統開發者們的基本請求是保持穩定。
C+ +會改進，但是這些改進將主要是為了反映從實踐中得來的經驗教訓，而不會是為了追風尚趕時髦。為了更高效地使用一些新的編程技術，比如通用編程技術，可能會增加一些小的特性。會有大量的庫涌現，我預期會出現一種嶄新的、更出色的庫支持機制。我希望新的擴展主要集中在支持抽象方面的一般特性，而不是為支持某些特殊任務的特定機制。
例如，“屬性”這個概念是很有用的，但我不認為在一種通用編程語言中有它的容身之地。用標準C++的一組類可以很容易地支持這一概念。如果我們感覺那族類對于“屬性”這一概念的支持不盡如人意，也不會立刻跑去在語言里增加屬性機制，而是仔細考慮如何改進類和模板以幫助庫設計人員盡可能接近“屬性”這個概念。也許通過改進函數對象的機制能夠給這個問題一個滿意的答復。
為了使C++在接下來的十幾年中保持靈活可變，很基本的一點就是不要讓標準C++趕什么學術或者商業的時髦。人們要求增加的特性中很大一部分通過使用現有的標準C++開發新庫的方式都可以實現。還有，事實上人們渴望得到的很多特性已經被包括在標準C++中，并且被最新的編譯器支持。對許多程序員來說，提高代碼質量的最佳途徑不是追求什么語言擴展，而是好好地、慢慢地品味最新的C++技術書籍。
20. 您怎么看待腳本語言的興旺態勢？特別是Python，似乎提供了一種學習OO技術的更簡單的途徑。
有些語言很不錯。比如Python，我很喜歡。但是我認為你從不同的語言中學到的OO技術是不完全相同的。當然，每一個專業的程序員都需要通曉幾門語言，并且了解各種語言在編程和設計技術上的不同。
在我看來，用腳本語言建造的系統與用C++那樣的通用語言建造的系統大不相同。從兩類語言中學到的技術區別明顯。在OO技術里也不存在什么通用部分對于各種系統的高效建造來說都是至關重要的。
21. 有沒有計劃往標準C++里增加一些新的特性以支持分布式計算？
沒有，我也不認為有這個必要。用更好的庫就差不多能解決問題了。最多，為了支持這類的庫，我們可能會增加一些低級的原操作和規則。
22. 未來C++有沒有可能定一個可移植的二進制接口？
如果你說的“可移植”是指跨硬件和塊操作系統的可移植，我想回答是不會。我們當然可以設計一個解釋器或者虛擬機（如同Java的做法——譯者），但這樣一來，由于無法以最優的方式訪問系統資源，C++的能力就會受到削弱，我真正希望在不遠的將來能夠看見的東西是platform ABIs。例如，有人正在努力為Intel新的IA64體系定義C++ ABI，我想這些努力會得到用戶們的巨大支持。
能夠把不同編譯器產生的代碼編譯在一起將會是一項十分有意義的事情。
23. 在不少流行領域，C++正在漸漸失去光芒，因為它要求人們花很大的精力去對付一些很基本的工作，比如管理內存（因為沒有垃圾收集機制），管理模塊之間的依賴性（因為沒有包機制），管理組件的版本。C++缺乏一些現代語言已經視為標準的特性。比如傳言中最酷的Java語言就特別重視這些問題。那么在解決這些問題是否會導致C++的發展背離其根本宗旨呢？C++應該怎樣發展以保證我們在這種語言上的投資能有合理的回報，而不是被迫去重新使用另一種語言？
我倒還沒有注意到C++比以前用的少了。相反，我看到的指標表明C+的使用還在穩定地增長著。只不過這種基數很大的穩定增長以及在標準性、移植性和庫方面的不斷提高并沒有造成什么具有欺騙性的新聞效應而已。我認為你所說的“失去光芒”只不過是市場推銷和新聞意義上的現象。
如果你需要垃圾收集機制的話，你可以在C++應用程序中插入一個垃圾收集器。有不少自由的和商業的垃圾收集器已經在重要的實踐中被證明是很出色的。
如果你不想使用垃圾收集機制，也沒關系。你可以使用標準容器類，它們大大減少了對于顯式分配和回收內存的需要。這樣，使用現代的庫和現代的編程風格，你能夠避免大部分的內存管理問題。
同樣的技術還能夠用來避免一般資源的管理問題。并不是只有內存才會泄漏，線程句柄、文件、互斥鎖、網絡連接等都是重要的資源，為了建立可靠的系統，這些資源必須被正確的管理。如果你覺得有了垃圾收集機制就可以解決所有的資源管理問題，那么你最好趕快從美夢中醒來。
C++提供了很多機制來管理一般性的資源。關鍵的手段——“獲取資源就是初始化”——可以使用函數對象來管理生存期問題。語言中關于對象的局部構造和異常機制對這項技術提供了支持。
某些語言的狂熱支持者總是用諷刺漫畫的筆法描述C++，然而C++實際上要好得多。特別是我覺得很多其他的特性已經泛濫不堪了，在C++中，通常這些特性能夠很容易的被模擬出來。相反的，新的語言在推廣的過程中總是不斷地增加新的特性，這就是為什么從一種語言誕生到被廣泛使用，其體積通常會增加個兩三倍。
目前，做為個人和組織，對于C++的最好投資就是去更好地理解標準C++和現代的C++設計編程技術。大多數人使用C++的方式實際上停留80年代中期的水平，甚至比那更陳舊。
至于模塊依賴性問題，我的觀點是，在編程語言的工作和系統的工作之間應該有一個明顯的界線，依賴關系應該盡可能地與編程語言分開，而由系統來支持。
我不認為組建版本的問題應該由編程語言來解決，這是一個系統范疇里的問題，在語言里應該通過提供相應的庫來解決。C++有這樣的機制。解決這樣的問題不會使 C++偏離軌道。但是給C++增加很多特殊的特性就會使C++偏離軌道，而且在保持可移植性和平臺獨立性方面也會是一個倒退。
24. 標準C++推出有段時間了，Java也大踏步地往前走而且取得了顯著的進步，您現在怎么比較Java與C++？您覺得Java想要變成像C++一樣“好” 的語言還需要做些什么？您舉的C++從Java身上學到了什么經驗嗎？有沒有什么Java的特性您認為是可以被C++吸納的？
我不比較語言。做好這項工作是十分困難的，而且很少具有專業水準。
我認為C++的進步會是主要以它的用戶在使用中遇到的問題以及其自身邏輯為基礎。當然，其他語言中的某些思想也會被考慮，但不能被簡單的移花接木過來。你必須審視那些機制在技術上和思想上的背景，并且找到在C++中支持這些技術的最佳方案。
有時最好的選擇是綜合使用幾種語言。畢竟沒有任何一種語言是放之四海而皆優的。C++現在是，將來也繼續會是在廣泛應用領域中最好的語言之一。但是，我們不能被拉下水，不能把所有可能的特性都加到C++里面來向大眾獻媚。我認為Java和C++現在和將來都會是十分不同的語言，語法相似，但背后的對象模型明顯不同。
對于我來說，一個很重要的區別是C++有一個ISO標準，而Java則是一個專有語言。
25. 在Java剛剛出現的那幾年，有很多欺騙性的言論說它將會是終極語言，會取代C++。您覺得在過去兩三年里Java對C++的追隨者們有什么影響？
到現在關于Java的不實之辭也還隨處可見。暫且不提Java在過去5年間的創紀錄的發展，狂熱的大眾似乎認為Java將最終取代的不僅僅是C++，而且還有所有其他的編程語言。但在另一方面，C++的使用仍在繼續增長。我不認為Java對于C++的影響已經使得人們轉而把本來打算用來創造更好的C++工具庫的資源調過去開發Java工具庫。Java對于學習編程的人來說沒有太多的新東西，所以對于C++的定義也沒什么影響。在那個領域，Java還得努力追趕。例如，我認為為Sun遲早會往Java里加入類似模板的機制。
人們應該認識到C++和Java的目標是何等的不同。 以C++的設計理念來衡量Java，或是以Java的設計理念來衡量C++，得出的結論都不會很好。
在訪談即將結束時，或許我該再次表明態度：C++仍然是我喜愛的語言，在寫代碼時你會發現沒有那種語言能像它那樣在如此廣泛的應用領域和平臺上同時達成如此的高效與精致。