請談談C++書

　　沒有，也不可能有一本書對於所有人來說都是最好的。不過對於那些真正的程序員來說，如果他喜歡從“經典風格”的書中間學習一些新的概念和技術， 我推薦我的

學習C++要花多長時間？

　　這要看你說的“學習”是什麼意思了。如果你是一個Pascal程序員，你應該能很快地使你的C++水平達到與Pascal相近的程度；而如果你是一個C程序員，一天之內你就能學會使用C++進行更出色的C風格編程。另一方面，如果你想完全掌握C++的主要機制，例如數據抽象，面向對象編程，通用 編程，面向對象設計等等，而此前又對這些東西不很熟悉的話，花上個一兩年是不足為奇的。那麼是不是說這就是學習C++所需要的時間呢？也許再翻一番，我想打算成為更出色的設計師和程序員最起碼也要這麼長的時間。如果學習一種新的語言不能使我們的工作和思想方式發生深刻的變革，那又何苦來哉？跟成為一個鋼琴家或者熟練掌握一門外語相比，學習一種新的、不同的語言和編程風格還算是簡單的。

瞭解C是學習C++的先決條件嗎？

　　否！C++中與C相近的子集其實比C語言本身要好學，類型方面的錯誤會少一些，也不像C那樣繞圈子，還有更好的支持庫。所以應該從這個子集開始學習C++。

要想成為真正的OO程序員，我是不是得先學習Smalltalk？

　　否。如果你想學Smalltaok，儘管去學。這種語言很有趣，而且學習新東西總是一個好主意。但是Smalltalk不是C++，而且把 Smalltalk的編程風格用在C++裡不會有什麼好結果。如果你想成為一個出色的C++程序員，而且也沒有幾個月的時間百無聊賴，請你集中力量學好 C++以及其背後的思想 。

我如何開始學習C++？

　　這取決於你的基礎和學習動機。如果你是個初學者，我想你最好找個有經驗的程序員來幫助你，要不然你在學習和實踐中不可避免的犯下的種種錯誤會大 大地打擊你的積極性。另外，即使你的編譯器配備了充足的文檔資料，一本C++書籍也永遠是必不可少的，畢竟文檔資料不是學習編程思想的好教材。

　　選擇書籍時，務必注意該書是不是從一開始就講授標準C++，並且矢志不渝地使用標準庫機制。例如，從輸入中讀取一個字符串應該是這樣的：

<code>　　string s; // Standard C++ style

　　cin >> s;

　　而不是這樣的：

　　char s[MAX]; /* Standard C style */

　　scanf("%s",s);/<code>

　　去看看那些紮實的C++程序員們推薦的書吧。記住，沒有哪本書對所有人來說都是最好的。

　　另外，要寫地道的C++程序，而避免用C++的語法寫傳統風格的程序，新瓶裝舊酒沒多大意義。

怎樣改進我的C++程序？

　　不好說。這取決於你是怎麼使用該語言的。大多數人低估了抽象類和模板的價值，反過來卻肆無忌憚地使用造型機制(cast)和宏。這方面可以看看 我的文章和書。抽象類和和模板的作用當然是提供一種方便的手段建構單根的類層次或者重用函數，但更重要的是，它們作為接口提供了簡潔的、邏輯性的服務表示 機制。

語言的選擇是不是很重要？

　　是，但也別指望奇蹟。很多人似乎相信某一種語言能夠解決他們在系統開發中遇到的幾乎所有問題，他們不斷地去尋找完美的編程語言，然後一次次的失 敗，一次次的沮喪。另外一些人則將編程語言貶為無關緊要的細節，把大把大把的銀子放在開發流程和設計方法上，他們永遠都在用著COBOL, C和一些專有語言。一種優秀的語言，例如C++，能幫助設計者和程序員做很多事情，而其能力和缺陷又能夠被清楚地瞭解和對待。

ANSI/ISO標準委員會是不是糟蹋了C++？

　　當然不是！他們（我們）的工作很出色。你可以在一些細節上找些歪理來挑刺，但我個人對於這種語言以及新的標準庫可是欣欣然。ISO C++較之C++的以前版本更出色更有條理。相對於標準化過程剛剛開始之初，你今天可以寫出更優雅、更易於維護的C++程序。新的標準庫也是一份真正的大 禮。由於標準庫提供了strings, lists, vectors, maps以及作用於其上的基本算法，使用C++的方式已經發生了巨大的變化。

你現在有沒有想刪除一些C++特性？

　　沒有，真的。問這些問題的人大概是希望我回答下面特性中的一個：多繼承、異常、模板和RTTI。但是沒有它們，C++就是不完整的。在過去的N年中，我已經反覆考慮過它們的設計，並且與標準委員會一起改進了其細節，但是沒有一個能被去掉又不引起大地震。

　　從語言設計的角度講，我最不喜歡的部分是與C兼容的那個子集，但又不能把它去掉，因為那樣對於在現實世界裡工作的程序員們來說傷害太大了。 C++與C兼容，這是一項關鍵的設計決策，絕對不是一個叫賣的噱頭。兼容性的實現和維護是十分困難的，但確實使程序員們至今受益良多。但是現在，C++已 經有了新的特性，程序員們可以從麻煩多多的C風格中解脫出來。例如，使用標準庫裡的容器類，象vector, list, map, string等等，可以避免與底層的指針操作技巧混戰不休。

如果不必和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#語言？

　　就C#語言本身我沒什麼好說的。想讓我相信這個世界還需要另外一個專有的語言可不是一件容易的事，而且這個語言還是專門針對某一個專有操作系統的，這就更讓我難以接受。直截了當地說，我不是一個專有語言的痴迷者，而是一個開放的正式標準的擁護者。

在做大項目時，您是不是真的推薦Ada，而不是C++？

　　當然不是。我不知道這是誰傳出來的謠言，肯定是一個Ada信徒，要麼是過分狂熱，要麼是不懷好意。

你願不願意將C++與別的語言比較？

　　抱歉，我不願意。你可以在The Design and Evolution of C++的介紹性文字裡找到原因。

　　有不少書評家邀請我把C++與其它的語言相比，我已經決定不做此類事情。在此我想重申一個我很久以來一直強調的觀點：語言之間的比較沒什麼意 義，更不公平。主流語言之間的合理比較要耗費很大的精力，多數人不會願意付出這麼大的代價。另外還需要在廣泛的應用領域有充分經驗，保持一種不偏不倚、客 觀獨立的立場，有著公正無私的信念。我沒時間，而且作為C++的創造者，在公正無私這一點上我永遠不會獲得完全的信任。

　　人們試圖把各種語言拿來比較長短，有些現象我已經一次又一次地注意到，坦率地說我感到擔憂。作者們盡力表現的公正無私，但是最終都是無可救藥的 偏向於某一種特定的應用程序，某一種特定的編程風格，或者某一種特定的程序員文化。更糟的是，當某一種語言明顯地比另一種語言更出名時，一些不易察覺的偷 梁換柱就開始了：比較有名的語言中的缺陷被有意淡化，而且被拐彎抹角地加以掩飾；而同樣的缺陷在不那麼出名的語言裡就被描述為致命硬傷。類似的，有關比較 出名的語言的技術資料經常更新，而不太出名的語言的技術資料往往是幾年以前的，試問這種比較有何公正性和意義可言？所以我對於C++之外的語言的評論嚴格 限制在一般性的特別特定的範疇裡。

顯然，這幾年世界變了，正在走向一個以Web為中心、分佈式計算為主流的時代。你覺得C++還能維持其地位嗎？程序員們可不可能把若干種專用語言（比 如Perl、Javascript）綜合運用以徹底取代某一種通用語言？（C++就是這樣的通用語言——譯者）為了配合新的計算模式，C++及其標準庫應 該做怎樣的調整？

　　從來沒有哪一種語言能適合所有的工作，我恐怕以後也不會有。實際系統通常是用多種語言和工具構造起來的。C++只是想成為若干語言和工具中的一 個，當某些專用語言在其領域裡特別突出時，它們可以與C++互為補充。也就是說，我覺得如果大多數現在的專用語言能借助特定領域的C++庫共同工作的話， 它們會表現得更出色。腳本語言通常導致難以維護的代碼，而且也沒有給程序的結構、可擴展性和可維護性的優化留下什麼餘地。

　　我不敢肯定未來的代碼是否真的會是以Web為中心的。就算是直接處理Web的系統也主要是由處理本地資源，如IP連接之類的程序模塊構成的。

　　地理上的分佈性以及服務器軟件對於併發機制的高度依賴對於系統的建造者來說的確是個挑戰。有些針對上述問題的庫已經出現，也許我們將會看到它們最終得以標準化。當然，一些原操作和保證規則應該被加到核心語言中以提供對這些庫的更佳支持。

　　總的來說，對於Web和網絡，我們非常需要一個真正的系統/網絡級的安全模型。指望JavaScript之類的腳本語言實現這個模型無異於白日做夢。注意，我也沒說C++提供了這個問題的解決方式。C++的重心是高效的訪問系統資源，而不是反欺詐。

C++未來的走向如何？在接下來的10年裡它會衰落嗎？或者是基本保持現在的形式？或者發展變化呈不同的形式？

　　C++有著最美好的未來。用它你能寫出偉大的代碼。除了故意進行惡意欺詐，C++仍將是開發高性能、高複雜度系統的最好語言。據我所知，沒有那種語言能在通用性、效率和精緻三方面的統一上可與C++相提並論。

　　我沒看到C++有衰落的徵兆。在我能預見的未來裡，它的用途還會不斷增長。當然，在未來的十年裡我們會看到一些變化，但不會像你想得那麼顯著。跟每一種語言一樣，C++也會發展變化。“語言專家們”要求改進的喧囂聲震耳欲聾，但是系統開發者們的基本請求是保持穩定。

　　C++會改進，但是這些改進將主要是為了反映從實踐中得來的經驗教訓，而不會是為了追風尚趕時髦。為了更高效地使用一些新的編程技術，比如通用 編程技術，可能會增加一些小的特性。會有大量的庫湧現，我預期會出現一種嶄新的、更出色的庫支持機制。我希望新的擴展主要集中在支持抽象方面的一般特性， 而不是為支持某些特殊任務的特定機制。

未來C++有沒有可能定一個可移植的二進制接口？

　　如果你說的“可移植”是指跨硬件和塊操作系統的可移植，我想回答是不會。我們當然可以設計一個解釋器或者虛擬機（如同Java的做法——譯 者），但這樣一來，由於無法以最優的方式訪問系統資源，C++的能力就會受到削弱，。我真正希望在不遠的將來能夠看見的東西是platform ABIs。例如，有人正在努力為Intel新的IA64體系定義C++ ABI，我想這些努力會得到用戶們的巨大支持。

　　能夠把不同編譯器產生的代碼編譯在一起將會是一項十分有意義的事情。

標準C++推出有段時間了，Java也大踏步地往前走而且取得了顯著的進步，你現在怎麼比較Java與C++？您覺得Java想要變成像C++一樣“好” 的語言還需要做些什麼？您舉的C++從Java身上學到了什麼經驗嗎？有沒有什麼Java的特性您認為是可以被C++吸納的？

　　我不比較語言。做好這項工作是十分困難的，而且很少具有專業水準。

　　我認為C++的進步會是主要以它的用戶在使用中遇到的問題以及其自身邏輯為基礎。當然，其他語言中的某些思想也會被考慮，但不能被簡單的移花接木過來。你必須審視那些機制在技術上和思想上的背景，並且找到在C++中支持這些技術的最佳方案。

　　有時最好的選擇是綜合使用幾種語言。畢竟沒有任何一種語言是放之四海而皆優的。C++現在是，將來也繼續會是在廣泛應用領域中最好的語言之一。 但是，我們不能被拉下水，不能把所有可能的特性都加到C++裡面來向大眾獻媚。我認為Java和C++現在和將來都會是十分不同的語言，語法相似，但背後 的對象模型明顯不同。

　　對於我來說，一個很重要的區別是C++有一個ISO標準，而Java則是一個專有語言。

（對此你對C++有何看法歡迎留言！）

閱讀更多 Python大數據工程師 的文章

關鍵字: 設計 Smalltalk 面向對象編程