程序員孟岩

❶ Linux C++ 伺服器端這條線怎麼走一年半能做出什麼

既然你是在校學生，而且編程語言和數據結構的基礎還不錯，我認為應該在《操作系統》和《計算機體系結構》這兩門課上下功夫，然後才去讀編程方面的 APUE、UNP 等書。

下面簡單談談我對學習這兩門課的看法和建議，都是站在服務端程序員的角度，從實用主義（pragmatic）的立場出發而言的。

學習操作系統的目的，不是讓你去發明自己操作系統內核，打敗 Linux；也不是成為內核開發人員；而是理解操作系統為用戶態進程提供了怎樣的運行環境，作為程序員應該如何才能充分利用好這個環境，哪些做法是有益的，哪些是做無用功，哪些則是幫倒忙。

學習計算機體系結構的目的，不是讓你去設計自己的 CPU（新的 ISA 或微架構），打敗 Intel 和 ARM；也不是參與到 CPU 設計團隊，改進現有的微架構；而是明白現代的處理器的能力與特性（例如流水線、多發射、分支預測、亂序執行等等指令級並行手段，內存局部性與 cache，多處理器的內存模型、能見度、重排序等等），在編程的時候通過適當組織代碼和數據來發揮 CPU 的效能，避免 pitfalls。Modern Microprocessors

這兩門課程該如何學？看哪些書？這里我告訴你一個通用的辦法，去美國計算機系排名靠前的大學的課程主頁，找到這兩門課最近幾年的課程大綱、講義、參考書目、閱讀材料、隨堂練習、課後作業、編程實驗、期末項目等，然後你就心裡有數了。

學習任何一門課程都要善於抓住主要矛盾、分清主次、突出重點，關鍵是掌握知識框架，學會以後真正有用的知識和技能，而不要把精力平均分配在一些瑣事上。

請允許我再次引用孟岩的觀點：http://blog.csdn.net/myan/article/details/5877305
我（孟岩）主張，在具備基礎之後，學習任何新東西，都要抓住主線，突出重點。對於關鍵理論的學習，要集中精力，速戰速決。而旁枝末節和非本質性的知識內容，完全可以留給實踐去零敲碎打。

原因是這樣的，任何一個高級的知識內容，其中都只有一小部分是有思想創新、有重大影響的，而其它很多東西都是瑣碎的、非本質的。因此，集中學習時必須把握住真正重要那部分，把其它東西留給實踐。對於重點知識，只有集中學習其理論，才能確保體系性、連貫性、正確性，而對於那些旁枝末節，只有邊干邊學能夠讓你了解它們的真實價值是大是小，才能讓你留下更生動的印象。如果你把精力用錯了地方，比如用集中大塊的時間來學習那些本來只需要查查手冊就可以明白的小技巧，而對於真正重要的、思想性東西放在平時零敲碎打，那麼肯定是事倍功半，甚至適得其反。

因此我對於市面上絕大部分開發類圖書都不滿——它們基本上都是面向知識體系本身的，而不是面向讀者的。總是把相關的所有知識細節都放在一堆，然後一堆一堆攢起來變成一本書。反映在內容上，就是毫無重點地平鋪直敘，不分輕重地陳述細節，往往在第三章以前就用無聊的細節謀殺了讀者的熱情。

比如說操作系統，應該把精力主要放在進程管理與調度、內存管理、並發編程與同步、高效的IO等等，而不要過於投入到初始化（從 BIOS 載入引導扇區、設置 GDT、進入保護模式）這種一次性任務上。我發現國內講 Linux 內核的書往往把初始化的細節放在前幾章，而國外的書通常放附錄，你可以體會一下。初始化對操作系統本身而言當然是重要的，但是對於在用戶態寫服務程序的人來說，弄清楚為什麼要打開 PC 上的 A20 地址線真的有用處嗎？（這不過是個歷史包袱罷了。）

再比方說《計算機網路》，關鍵之一是理解如何在底層有丟包、重包、亂序的條件下設計出可靠的網路協議，這不算難。難一點的是這個可靠協議能達到「既能充分利用帶寬，又能做到足夠公平（並發連接大致平均分享帶寬）」。而不是學會手算 CRC32，這更適合放到資訊理論或別的課程里去講。

注意分清知識的層次。就好比造汽車與開汽車的區別，我認為一個司機的技能主要體現在各種道路條件和天氣狀況下都能安全駕駛（城市道路、高速公路、鄉間公路 X 晴、雨、雪、霧），平安到達目的地。作為一名司機，了解汽車運行的基本原理當然是好事，可以有助於更好地駕駛和排除一些常見故障。但不宜喧賓奪主，只要你不真正從事汽車設計工作，你再怎麼研究發動機、傳動、轉向，也不可能比汽車廠的工程師強，畢竟這是人家的全職工作。而且鑽研汽車構造超過一定程度之後，對開好車就沒多大影響了，成了個人興趣愛好。「有的人學著學著成了語言專家，反而忘了自己原本是要解決問題來的。」（語出孟岩 快速掌握一個語言最常用的50%）

對於並發編程來說，掌握 mutex、condition variable 的正確用法，避免誤用（例如防止 busy-waiting 和 data race）、避免性能 pitfalls，是一般服務端程序員應該掌握的知識。而如何實現高效的 mutex 則是 libc 和 kernel 開發者應該關心的事，隨著硬體的發展（CPU 與內存之間互聯方式的改變、核數的增加），最優做法也隨之改變。如果你不能持續跟進這一領域的發展，那麼你深入鑽研之後掌握的知識到了幾年之後可能反而成為累贅，當年針對當時硬體的最優特殊做法（好比說定製了自己的 mutex 或 lock-free 數據結構）在幾年後有可能反而會拖低性能。還不如按最清晰的方式寫代碼，利用好語言和庫的現成同步設施，讓編譯器和 libc 的作者去操心「與時俱進」的事。

注意識別過時的知識。比方說《操作系統》講磁碟IO調度往往會講電梯演算法，但是現在的磁碟普遍內置了這一功能（NCQ），無需操作系統操心了。如果你在一個比較好的學校，操作系統課程的老師應該能指出這些知識點，避免學生浪費精力；如果你全靠自學，我也沒什麼好辦法，盡量用新版的書吧。類似的例子還有《計算機體系結構》中可能會講 RISC CPU 流水線中的 delay slot，現在似乎也都廢棄了。《計算機網路》中類似的情況也不少，首先是 OSI 七層模型已經被證明是扯淡的，現在國外流行的教材基本都按五層模型來講（Internet protocol suite），如果你的教材還鄭重其事地講 OSI （還描繪成未來的希望），扔了換一本吧。其次，區域網層面，乙太網一家獨大（幾乎成了區域網的代名詞），FDDI/Token ring/ATM 基本沒啥公司在用了。就說乙太網，現在也用不到 CSMA/CD 機制（因為 10M 的同軸電纜、10M/100M 的 hub 都過時了，交換機也早就普及了），因此碰撞檢測演算法要求「乙太網的最小幀長大於最大傳播延遲的二倍」這種知識點了解一下就行了。

另外一點是 low level 優化的知識非常容易過時，編碼時要避免過度擬合（overfitting）。比方說目前國內一些教科書（特別是大一第一門編程語言的教程）還在傳授「乘除法比加減法慢、浮點數運算比整數運算慢、位運算最快」這種過時的知識。現代通用 CPU 上的實際情況是整數的加減法和乘法運算幾乎一樣快，整數除法慢很多；浮點數的加減法和乘法運算幾乎和整數一樣快，浮點數除法慢很多。因此用加減法代替乘法（或用位運算代替算術運算）不見得能提速，反而讓代碼難懂。而且現代編譯器可以把除數為小整數的整數除法轉變為乘法來做，無需程序員操心。（目前用浮點數乘法代替浮點數除法似乎還是值得一做的，例如除以10改為乘以0.1，因為浮點運算的特殊性（不滿足結合律和分配率），阻止了編譯器優化。）

類似的 low level 優化過時的例子是早年用匯編語言寫了某流行圖像格式的編解碼器，但隨著 CPU 微架構的發展，其並不比現代 C 語言（可能用上 SIMD）的版本更快，反而因為使用了 32-bit 匯編語言，導致往 64-bit 移植時出現麻煩。如果不能派人持續維護更新這個私有庫，還不如用第三方的庫呢。現在能用匯編語言寫出比 C 語言更快的代碼幾乎只有一種可能：使用 CPU 的面向特定演算法的新指令，例如 Intel 的新 CPU （將會）內置了 AES、CRC32、SHA1、SHA256 等演算法的指令。不過主流的第三方庫（例如 OpenSSL）肯定會用上這些手段，及時跟進即可，基本無需自己操刀。（再舉一個例子，假如公司早先用匯編語言寫了一個非常高效的大整數運算庫，一直運轉良好，原來寫這個庫的高人也升職或另謀高就了。Intel 在 2013 年發布了新微架構 Haswell，新增了 MULX 指令，可以進一步提高大整數乘法的效率 GMP on Intel Haswell ，那麼貴公司是否有人持續跟進這些 CPU 的進化，並及時更新這個大整數運算庫呢？或者直接用開源的 GMP 庫，讓 GMP 的作者去操心這些事情？）

如果你要記住結論，一定要同時記住前提和適用條件。在錯誤的場合使用原本正確的結論的搞笑例子舉不勝舉。

《Linux內核源碼情景分析》上分析內核使用 GDT/LDT 表項的狀況，得出進程數不超過 4090 的結論。如果你打算記住這個結論，一定要記住這是在 Linux 2.4.0 內核，32-bit Intel x86 平台上成立，新版的內核和其他硬體平台很可能不成立。看完書後千萬不要張口就來「書上說 Linux 的最大進程數是 4090」。

一個 Linux 進程最多創建 300 余個線程，這個結論成立的條件是 3GB 用戶空間，線程棧為 10M 或 8M。在 64-bit 下不成立。
Reactor 模式只能支持不超過 64 個 handle，這個結論成立的條件是 Windows 下使用 WaitForMultipleObjects 函數實現的 WFMO_Reactor，對於 Linux 下使用 poll/epoll 實現的 Reactor 則無此限制。
C++ STL 的 vector 容器在 clear() 之後不會釋放內存，需要 swap(empty vector)，這是有意為之（C++11 里增加了 shrink_to_fit() 函數）。不要記成了所有 STL 容器都需要 swap(empty one) 來釋放內存，事實上其他容器（map/set/list/deque）都只需要 clear() 就能釋放內存。只有含 reserve()/capacity() 成員函數的容器才需要用 swap 來釋放空間，而 C++ 里只有 vector 和 string 這兩個符合條件。

最後一點小建議，服務端開發這幾年已經普及 64-bit 多核硬體平台，因此在學習操作系統的時候，可以不必太關心單核上特有的做法（在單核時代，內核代碼進入臨界區的辦法之一是關中斷，但到了多核時代，這個做法就行不通了），也不必太花精力在 32-bit 平台上。特別是 32-bit x86 為了能支持大內存，不得已有很多 work around 的做法（困難在於 32-bit 地址空間不夠將全部物理內存映射入內核），帶來了額外的復雜性，這些做法當時有其積極意義，但現在去深入學似乎不太值得。

關於項目，我出兩個練手題目：

一、多機數據處理。有 10 台機器，每台機器上保存著 10 億個 64-bit 整數（不一定剛好 10 億個，可能有上下幾千萬的浮動），一共約 100 億個整數（其實一共也就 80GB 數據，不算大，選這個量級是考慮了 VPS 虛擬機的容量，便於實驗）。編程求出：
1. 這些數的平均數。
2. 這些數的中位數。
3. 出現次數最多的 100 萬個數。
*4. （附加題）對這 100 億個整數排序，結果順序存放到這 10 台機器上。
*5. （附加健壯性要求）你的程序應該能正確應對輸入數據的各種分布（均勻、正態、Zipf）。
*6. （附加伸縮性要求）你的程序應該能平滑擴展到更多的機器，支持更大的數據量。比如 20 台機器、一共 200 億個整數，或者 50 台機器、一共 500 億個整數。

二、N-皇後問題的多機並行求解。利用多台機器求出 N-皇後問題有多少個解。（注意目前的世界紀錄是 N = 26，A000170 - OEIS ）
1. 8 皇後問題在單機上的運算時間是毫秒級，有 92 個解，編程實現之。
2. 研究 N-皇後問題的並行演算法，寫一個單機多線程程序，爭取達到線性加速比（以 CPU 核數計）。再設法將演算法擴展到多機並行。
3. 用 10 台 8 核的機器（一共 80 個 CPU cores），求解 19-皇後和 20-皇後問題，看看分別需要多少運行時間。你的方案能否平滑擴展到更多的機器？
*4. （附加題）如果這 10 台機器的型號不一，有 8 核也有 16 核，有舊 CPU 也有更快的新 CPU，你該採用何種負載均衡策略，以求縮短求解問題的時間（至少比 plain round-robin 演算法要好）？

你可以用 Amazon EC2 或 Google GCE 來驗證你的程序的正確性和性能，這兩家的虛擬機都是按小時（甚至更短）收費，開 10 台虛擬機做一個下午的實驗也花不了多少錢。

❷ 有人超越C++之父嗎

C ++ 的 背 影
——C++之父Bjarne Stroustrup印象 左輕侯 2002.11.4
熱愛C++的朋友請不要誤會，我並不是在暗示「C++已經日薄西山」，或者任何類似的意思。從語義上來說，C++作為一門編程語言，當然不會有什麼背影。事實上，我想說的是一個人的背影。因此這個題目顯得有點突兀，甚至嘩眾取寵。但是我想，在C++社群中，每一個人都會同意，有一個名字就是C++的象徵。這個名字當然就是Bjarne Stroustrup。
Bjarne Stroustrup博士，1950年出生於丹麥，先後畢業於丹麥阿魯斯大學和英國劍橋大學，AT&T大規模程序設計研究部門負責人，AT&T 貝爾實驗室和ACM成員。1979年，Stroustrup開始開發一種語言，當時稱為"C with Class"，後來演化為C++。1998年，ANSI/ISO C++標准建立，同年，Stroustrup推出其經典著作The C++ Programming Language的第三版。
2002年10月，Stroustrup首次訪問中國。
接觸IT界的時間越長，我就越明顯地發現，那些曾經在媒體上喧囂一時的話題，往往只是些無關緊要的事情，而真正有著深刻意義和影響的大事，卻很容易默默無聞。
Stroustrup的訪華，在技術圈子裡引起了很大的轟動。多少年來，中國的程序員一直通過翻譯的著作這樣的間接渠道（往往滯後時間很長），在黑暗中辛苦摸索。直到互聯網普及之後，我們才能夠通過網路在第一時間追蹤最新的技術，與國外的同行進行技術交流，慢慢地、一步步地拉近與世界的距離。今天，我們終於有機會當面請教這位世界級的大師，直接聆聽這個領域中最權威的聲音。我們再也不用費盡心思去琢磨蹩腳翻譯背後的作者的思想，不用迷惑於那些經常出自於一知半解的專家之口、不知道經過多少次轉述、真偽難辨的驚人之論了。在得知Stroustrup訪華的消息之後，我就和一些朋友談到，這是一個開始，希望中國的技術界能夠契此機會，依靠大家的努力，與國際上的技術社群建立穩定的交流機制，希望這件事標志著中國的程序員們不再是一個孤立、被國際社會遺忘的群體，真真正正成為世界大家庭的一員。
不過，除了主辦方做的一些宣傳之外，Stroustrup的到來，幾乎沒有見諸於任何主流媒體，雖然Stroustrup的成就和對計算機界的影響力，足以與當代任何一個人相比，雖然這次事件的意義，遠遠超過許多國內IT圈子裡的雞毛蒜皮。
Stroustrup的這次訪華，行經北京、西安、杭州、上海四個城市，時間長達半個月。在此期間，我有幸見過他三次。
第一次是他剛剛到達北京的第二天，華章的兩位朋友請他在北海後門的一家飯店吃飯，留了一個機會給我和他共進晚餐。我至今對北京的堵車痛恨無比，因為那天正好是周末，加上大雨，我竟然比預定的時間晚了一個多小時到達目的地。當我氣急敗壞地沖進那家飯店時，一眼就看到，在最靠裡面的角落裡，華章的兩位朋友中間，坐著一位老外。
他站起來，很有禮貌地和我握手。他本人和那張著名的照片（在C++社區中盡人皆知）上的樣子很象，有點禿頂，衣著隨便，與其說是一位來中國訪問的專家，不如說是一個在自己家中隨意進餐的藍領。我用英語結結巴巴地解釋了遲到的原因，他點著頭「哦」了好幾聲，一副「理解理解」的樣子，彷彿他也曾深受堵車之苦。雖然我們素昧平生，但對方的神情和簡單的幾句話，卻一下子拉近了我們的距離。這句話聽起來象書上的套話，但身臨其境的我，卻的確有這樣的感覺。
在這次見面之前，我曾經想像過Stroustrup會是一個什麼樣的人，會不會比較高傲。因為我知道，大凡超群絕倫的人物，往往在性格上都有一些偏執，何況以C++之父的身份？但是和我想像的完全相反，Stroustrup非常和善，具有技術人員特有的那種極佳的幽默感，很愛笑，甚至可以說有點天真。當我說了一句傾慕的話之後，他居然會象個孩子一樣不好意思。
飯店裡很吵，其實不是談話的好地方。我的口語水平本來就不好，大學畢業後又荒廢了好幾年，但是面對Stroustrup，不知為什麼，我居然勇氣百倍，用這種洋涇濱英語連說帶比劃，跟他說了一些事情。我告訴他，我翻譯過他的一個關於C++的風格與技術的FAQ，而且正在閱讀他的名著《C++程序設計語言》；我告訴他，中國有很多C++程序員，大家期待他的到來已經很久了；我告訴他，中國的程序員缺乏與國外社群的交流，希望我們能夠推動這種交流；我還為自己的口語水平而道歉（BS很理解地回答英語也不是他的母語），希望能夠通過Email交流……
然後Stroustrup用一連串低沉的英語作為回答，但並不是那種嚴肅的學術性的發言，而是說得很隨意，也很投入，顯然他在打動別人之前先打動了自己。說得精彩之處，他會左顧右盼，然後和我們一起開懷大笑。
這是一家普通的飯店，菜也是很普通的菜。BS和北京街頭隨處可見的老外並沒有多少區別。說著說著，我突然有一種沖動，我想，這些坐在我們旁邊自顧自高談闊論的人，會不會知道角落裡這個談笑風生、自得其樂的老外，就是一位震鑠當代的大師，一位為人類做出過偉大貢獻的人？
「人和人，真的是很不一樣……」我想。
由於BS明天一早還要趕飛機去西安，所以我們相聚的時間相當有限。出了店門，我們揮手告別。我的收獲是BS在《C++程序設計語言》中文版上的簽名和一張合影。
回到家裡，整個夜晚我都在房間走來走去。同租的室友問我：「你今天好象很激動啊？」
「當然，」我回答說，「因為我見到了這個領域的巔峰。」
Stroustrup的行程是先到北京安頓，然後飛往西安，按照西安-北京-杭州-上海這個順序進行正式訪問。在等待Stroustrup回北京的時候，我在csdn上看到了一個貼子：《Bjarne Stroustrup在西安的講座很令人失望》。點進去看，倒不是對講座的內容失望，而是批判舉辦活動中的一些現象，這也正是我最擔心的。其實我知道舉辦方作出了很大努力，有些技術上的問題情有可原，對於這次事件本身來說，算不得什麼大不了的事情。但是觸動我的是，文中說到Stroustrup演講完以後，聽眾們提問的情況。貼子的原文如下：
「……那位主持人在宣布開始提問後，就走了出去，之後混亂的場面就開始了，我坐在地板上聽了幾個問題，大多是問C++、C#、java哪門語言更好之類的問題，這些人可能並不了解Bjarne Stroustrup，他本人早都說過不會對語言的優劣進行評述，可這些人還是不停的問，甚至還有人問Bjarne Stroustrup，在計算機和自己的女朋友當中他更喜歡哪一個？是不是更喜歡計算機？這種問題，我不想作什麼評論，好好的機會，就這樣......唉！！我可以明顯的看到Bjarne Stroustrup的臉上有不悅的表情。在看到前面的人越聚越多，並開始拚命的想搶到話筒的時候，我決定還是早點離開為妙，我從地上站起身來,拍拍身上的塵土，大踏步的離開了。」
我以前並沒有和Stroustrup打過交道，也不知道他對中國的印象如何。我曾猜想過，Stroustrup是如何看待中國的？是不是把我們當作一個遙遠的蠻荒之地來看待，就象我們看待非洲某個小國一樣？如果真是這樣，那也一點都不奇怪，畢竟中國在國際上的形象是一個IT市場，而不是一個IT領跑者。當然隨便進行這種猜測是不禮貌的，但是那也要我們能夠贏得人家的尊敬才行。當得知有見到Stroustrup的機會時，我和朋友曾經互相勉勵：「不要丟中國程序員的臉啊。」
一年多以前，我曾對朋友說過：「這幾年中國程序員的水平是長進了很多，以前是不知道自己水平有多差，現在是知道自己水平有多差了。」IT技術的核心在國外，我們開放國門的時候也並不長，水平比不上人家，是沒有辦法的事情。知道自己水平差以後，無非是兩點，一是要承認現實，二是要想辦法追趕。
進入計算機這個行業以來，我已經見過了無數自以為或被人以為是高手的妄人，種種氣焰無庸詳說，盡管在Stroustrup面前他們連學生的資格都遠遠夠不上。中國到底有多少人在使用C++？有多少人對C++有深入全面的了解（雖然我知道水平高的人肯定是有的）？我們的民族軟體產業，到底是由一群什麼人在支撐？
期待中的大師終於來了，期望中的face-to-face的交流場面也終於出現了，面對顯示器屏幕，我突然有一種莫名的孤獨蒼涼的感覺。
第二次見到Stroustrup，也是在飯店裡，由我作東，北京的幾個程序員朋友和他進行一次小范圍的交流。該死的歷史又一次重演了，又是周末，又是大雨，我又一次遲到了。不同的是，當我再次氣急敗壞地沖進飯店時，看到了不同的場景。Stroustrup一個人坐在桌子的一邊，左右座位都是空的，其他人坐在他的對面，大家都不說話，只有他一個人在默默地吃東西。他好象已經習慣了我的遲到，問了我一句：「You got lost?」
也許是受到了這種氣氛的影響，我坐在他旁邊的時候，一時居然不知道應該說什麼好。雖然我很想為他在西安的遭遇說幾句道歉的話，但又開不了口。
他拿起手頭的一份英文報紙，指著上面的Texas大學對我說：「A small world.」原來他已經受聘擔任Texas大學的教授了。我問：「Then you leave AT&T?」他說AT&T仍然保留了他的位置。我還問過他關於Lippman加入微軟擔任VC.net首席架構師的事情，與我的預料不同，他似乎對微軟的編譯器評價很高。
但是總的來說，這一次Stroustrup比上一次要沉默得多，很少發笑，大多數時候都在默默吃東西。我終於忍不住，問了一個也許不太禮貌的問題：「Do you feel lonely in China?」Stroustrup沒有聽明白「lonely」這個詞，當他弄明白了之後，很嚴肅地說：「No.」他指指對面，又指指外面，說（當然是用英文）：「他們，還有很多人，他們都給了我很好的待遇。」「希望中國能給您留下一個好印象。」「現在就已經是這樣了。」但願如此。
吃完飯後，Stroustrup去賓館接受一家媒體的采訪。我和幾個朋友繼續聊天。雖然他們和我一樣，因為口語水平的限制，沒有能和Stroustrup暢所欲言，但是興奮之情都溢於言表。有一位還嚷嚷著要去報考Stroustrup的研究生，雖然後者說他已經收到了數以千計的application。
在白石橋的人行天橋上，望著黑暗的天空下來來往往的車流，我對一個朋友說，我為Stroustrup感到不平。象比爾·蓋茨、拉里·埃利森這種人訪華，都會享受國賓級的待遇，媒體上也會鋪天蓋地地宣傳。Stroustrup無論從成就還是從影響力上來說，都和他們是一個層次的，為什麼他的中國之行會這樣樸素、低調、默默無聞？對方略作思考後回答，因為蓋茨和埃利森都身為大商業公司的首腦，可以直接影響中國的市場和政府。而Stroustrup雖然發明了C++和實際掌握著C++語言的標准，但他對業界的影響並不那麼直接，他本人也不是有錢人。我說：「這個我也知道，但我還是為他感到不平。」
Stroustrup在1979年發明C++語言，至今已經二十多年，一直在為C++的完善、發展和標准化而奮斗。在在Stroustrup的理想中（也是他一直在不懈提倡的），C++應該是一種中立的、開放的、不依賴於任何平台的、不被任何一家商業公司所操縱的語言，它的標准掌握在ISO C++標准委員會中。在這一點上，C++和Delphi與Java這樣的語言有著本質的區別。
雖然C++出現得很早，但是它的ISO標准經過千錘百煉，遲至1998年才正式出台。Stroustrup不滿商業公司為了自己的利益，把C++變成各種亂七八糟的方言，花了很多心血在C++的標准化工作上面。在來自世界各地的志願者們的共同努力下，新的C++標准和標准庫都已經臻於完美。從這個意義上來說，Stroustrup創立的不僅僅是一種語言，而是一種文化。Stroustrup成功了（C++也許是當前使用最廣泛的通用工業語言），但他仍然有很多事情要做。Stroustrup的這次中國之行，可以看作是他和他的理念與中國軟體界的一次正面接觸。從我看到的情況來說，至少中國軟體界的氣氛，與Stroustrup渾身上下的氣質並不那麼相投。
網上有一個所謂IEEE對Stroustrup專訪的文章，很明顯是一個愚人節笑話，內容是Stroustrup宣揚他故意將C++設計得難以學習，是為了提高程序員的薪水。不知哪位好事之徒把它譯成了中文，導致了我幾乎在常去的每一個論壇（包括非技術性的論壇）上都發現了這個東西的轉貼（有時還是一而再再而三的轉貼），底下跟著一大堆煞有介事的評論。在後來的通信中，我把這個事告訴了Stroustrup，他顯然當成了笑話來聽，回答說：「It doesn't matter as long as they don't believe it.」
我該怎麼回答他，告訴他其實大家都信以為真？
最後一次見到Stroustrup，是在北京大學的一個C++語言研討會上。前一天在清華的演講我沒有去，據說相當成功。北大的這個研討會是內部性質的，規模不大，實行憑證入場的方式，應該是保證了參與者的質量。與會的還有幾位重量級的人物，包括《C++程序設計語言》的譯者、北大的裘宗燕教授，另外慕名而來的估計也不少。
我無論如何不能再遲到了，提前一個小時到了會場。我剛到，就陸陸續續有人進來了，一邊互相打聽著「C++之父的研討會是不是在這里」。很多人帶著Stroustrup著作的各種版本，估計是來尋求簽名的。終於，Stroustrup在華章公司和北大計科系的人的簇擁下出現了，今天他看起來精神不錯。
首先是Stroustrup做了一個題為《Speak C++ Like a Native》（將C++作為一種母語）的演講，概要地說明了C++的設計思想和幾種編程風格。內容比較基礎，而且在西安交大和清華做的演講也是這個，我沒有太在意。接下來是由舉辦方邀請的人進行比較正式的發言，裘宗燕第一，熊節第二，我排在第三個。我提的是一個關於通過C++語言開發跨平台程序的問題，詢問C++為什麼沒有一個象Delphi那樣的跨越平台的framework，以及將現有的標准庫是否有往這方面發展的意向。這個問題發揮的彈性很大，可以詳細討論，也可以幾句話帶過去。但是Stroustrup象回答前兩個問題一樣，非常詳盡和耐心地做了回答，從C++的目標和定位說起，談到標准庫和商業公司的專有庫的區別，談到因為資金問題標准庫不太可能發展成為包羅萬象的framework，最後建議我可以嘗試一些比較優秀的第三方庫。在說話的時候，Stroustrup一直注視著我的眼睛，不斷打著手勢，認真得讓我有愧疚的感覺，因為我的理解往往跟不上他的言鋒。
最精彩的是自由答問時間，很多人都已經躍躍欲試了。我已經無法詳細地回憶起當時的具體情形，總之發言非常踴躍。在我的印象中，似乎沒有出現特別有創意的問題（當然在這種即興發言中，很難出現這種好問題），不過大多數的問題都有相當的水平。其實不用聽他們問的內容，只需要看到那一張張神情專注而略顯緊張的年輕的臉，就能夠讓人產生一種熟悉而親切的感覺……毋庸諱言的是，其實有不少問題純屬浪費時間，因為類似的問題Stroustrup早已經回答過許多次了，在網上稍微查找一下就能找到答案。這種情況應該可以從一個側面說明，中國程序員作為一個整體，與國外的交流還是太少了，仍然缺乏放眼世界的胸襟和眼光。
「Stroustrup真可憐，被人一遍又一遍地問這些同樣的問題，」負責陪同Stroustrup的一位朋友忍不住嘀咕說，很容易想像，這種場面他已經見過好多回了。盡管如此，Stroustrup仍然不厭其煩地解答著每一個問題，認真得讓人想起近代歷史上的傳教士，這份耐心真是讓我佩服無己。很顯然，今天他興致很高，特別是遇到了good question的時候，發揮的時間遠遠超過了預定的期限。幾個小時的熱烈討論，讓Stroustrup已經略顯疲態，後來不得不背靠著牆壁說話（不知為何，他就是不願意規規矩矩地坐著，整個自由答問期間都是採用站立的姿勢，甚至常常用一隻腳踩在椅子上）。但是當主持者向他示意時間已到，可以結束時，他卻搖手反對，表示要繼續討論下去。現場發出了一片善意的笑聲……
晚飯由北大的一位副教授做東，作陪的有華章的幾位編輯，C-View的孟岩和王昕，科泰的陳榕。陳榕在微軟工作過多年，英語很好，和Stroustrup聊了很長時間，談的是業界的一些事情，基本上沒有涉及技術問題。
曲終人散，我們走出北大的校門，Stroustrup將在第二天飛往上海。臨上車之前，他很嚴肅地和我們中的每一個人握手道別，並表示感謝。不知中國之行帶給他的是什麼？但我知道，他帶給我們有很多，包括以後建立的聯系。在北京的夜色中，這個年過五十、頭發已經稍微有些花白的丹麥人轉身離去，留下一個沉默的背影。

再見，Stroustrup。

❸ java是誰發明的

十大事件與Java相關的四十個名字

1990－1994：Java緣起
文/孟岩

Larry Wall說，優秀程序員應有的三個特點:懶惰、急躁和傲慢。Java就是誕生在一群懶
惰、急躁而傲慢的程序天才之中。
1990年12月，Sun的工程師Patrick Naughton被當時糟糕的Sun C++工具折磨的快瘋了。
他大聲抱怨，並威脅要離開Sun轉投當時在Steve Jobs領導之下的NeXT公司。領導層為了
留住他，給他一個機會，啟動了一個叫做Stealth（秘密行動）的項目。隨著James
Gosling等人的加入，這個項目更名為Green。其目標是使用C++為嵌入式設備開發一種新
的基礎平台技術，James Gosling本人負責開發一個SGML編輯器。正如人們事後分析的那
樣，這位天才的程序員太懶惰，所以沒有把C++學好，開發中碰了一頭包;太急躁??所以
不願意停下來讀讀Scott Meyers的新書《Effective C++》;太傲慢??所以輕易地決定開
發一中新的編程語言。他把這種語言命名為C++++--，意思是C++「加上一些好東西，減
去一些壞東西」。顯然這個糟糕的名字不可能長命百歲，很快這種頗受同伴喜愛的小語
言被命名為Oak。
到了1992年9月，Oak語言連同Green OS和一些應用程序一起發布在稱做Start 7的小設備
上，從而使之有了第一次精彩的亮相。隨後，Sun開了一家名為FirstPerson的公司，整
個團隊被轉移到這家公司里研發機頂盒，以投標時代華納公司的一個項目。這幫天才被
技術狂熱所鼓舞，開發出了一個高交互性的設備，結果沒想到時代華納公司和有線電視
服務商並不願意用戶擁有那麼大的控制權，從而在競標之戰中敗給了SGI。Oak的鋒芒之
銳，竟然把客戶都給嚇懵了。Sun沮喪地關閉了FirstPerson，召回了整個團隊。事實證
明，傳統行業中那些腦滿肥腸的保守主義者是腐朽沒落的。回去！回到激情澎湃的IT產
業，抓住互聯網的大潮，這才是出路！1994年，Oak被命名為Java，針對互聯網的新一輪
開發如火如荼，一切已經就緒，熔岩在地下奔流，火山即將噴發。

1995: Java香濃世界
文/馬偉

1995年，Sun正式對外公布了Java，並且發布了JDK 1.0。這種外形酷似C++，卻包含一顆
Smalltalk般純潔的面向對象之心的全新程序設計語言及其平台，幾乎在一夜之間就成為
軟體產業的新寵兒。Java當時僅僅被用來為網站製作一些動態應用,諸如動畫圖片之類，
但這仍然引起了很多Web開發者們的注意，他們非常渴望有一種安全的語言，可以在靜態
的HTML網頁上製作動畫圖片。Sun最終把Java集成到NetScape瀏覽器。同時因為它具有
「只寫一次，隨處運行」的特性，而引起了很多開發者的注意，他們可以再也不用為了
使程序能夠在不同型號的硬體上運行而耗費大量的時間來編譯代碼了。
當時的Web瀏覽器的出現也為Java的出現起到了很好的推動作用，通過Java和Web瀏覽器
的結合，人們似乎看到了什麼，有人甚至預言PC將在一兩年內退出歷史的舞台，取而代
之的是基於Java的瀏覽器應用程序，通過網路計算設備來進行應用。Java的出現為當時
的軟體產業帶來了無限的遐想。

1996：Java大躍進，盟主地位就此定
文/馬偉

SUN在1996年一開始首先成立了JavaSoft組織，並在1月23日正式發布自己的Java 1.0，
作為20世紀業界出現的最重要的技術之一，Java引起了編程世界的革命。直到現在，
Java仍然是互聯網上最流行的語言。
在Sun正式發布Java 1.0之後，Java這門新生的語言就擁有了自己的會議??JavaOne，這
次會議初試啼音就吸引了600多名參與者。除了擁有這么多的積極參與者來進行Java的開
發之外，各大知名公司也紛紛向Sun申請Java的許可。一時間，NetScape、惠普、IBM、
Oralce、Sybase甚至當時剛推出Windows 95的微軟都是Java的追隨者。
Java的應用就像是世界上的頂級玩家們組成的一個公開聯盟，告訴全世界我們大家就是
都在用著Java。也正是因為如此，Java也找到了自己的歸宿。現在的J2EE已經成為中大
型企業級應用的標准，成為承接資料庫和Web之間的一個重要橋梁。
當年Java的機會實在太多了，以至於很難知道到底該做什麼。最終Java在應用伺服器市
場獲得了難以取代的地位，也確定了J2EE的發展方向，並且仍將延續下去。

1997-2001: 微軟與Sun的Java官司
文/孟岩

Java誕生的1995年，正是微軟在軟體產業地位達到巔峰的時代，Windows 95發布時的風
光場面給人們留下的深刻印象至今難忘。盡管如此，作為最卓越的技術領袖，比爾?蓋茨
仍然敏銳地注意到Java。當他了解了Java的一些細節之後，給予了這樣的評價:「Java是
很長時間以來最優秀的程序設計語言。」基於此，微軟於1996年3月申請並獲得了Java許
可證。微軟對於Java的這一熱情態度在當時大大提高了人們對Java的興趣和信心，但也
有不少人擔心微軟會依靠自己強大的影響力在標准之外另立標准，從而破壞Java的純潔
性。
果然，從1997年發布Visual J++的第一個版本開始，微軟就開始在Java中摻入自己的私
有擴展。這毫無疑問引起Sun的高度重視。1997年10月，Sun向美國加州地方法院起訴微
軟公司違反兩公司就微軟使用Java技術所簽定的合同，指控微軟公司在自己的Java產品
中做了「不恰當的修改」，違反了合同中承諾向用戶提供Java兼容產品的條款。這一官
司曠日持久，直到2001年1月雙方達成和解，微軟將繼續提供採用Sun開發的Java技術的
現有產品（包括測試版）。不過，Sun有限制地僅對包括Java 1.1.4的微軟產品提供許
可。到了2001年7月，微軟公布新版的Windows XP將不再支持Sun的JVM，並且推出了.NET
平台與Java分庭抗禮。
現在回過頭去看，當時的這一場官司對Java世界產生了深遠的影響。如果沒有這一場官
司，也許很多Java程序員都在使用Visual J++，基於WFC開發Windows客戶端程序，同時
不得不面對被兩個不同的事實標准所分裂的Java世界。

❹ 如何學好C++

程序員》推薦C++ 圖書三人談

主持人：熊節（透明），《程序員》雜志編輯，C-View成員
嘉 賓：孟岩（夢魘）,聯想公司掌上設備事業部應用開發處任職，C-View成員。與侯捷先生合譯《C++ Standard Library》一書
金尹（惡魔），上海天宇公司CTO，在《程序員》連載有「自由與繁榮的國度」系列文章

透明：「學C++用哪本書入門」，這是被問得最多的一個問題。但是哪一本書是最好的入門書？似乎很難找到答案。《C++ Primer》太厚，《Effective C++》對讀者要求比較高，《Essential C++》又常常被批評為「太淺」。
其實說穿了：no silver bullet。想從一本書學會C++，那是不可能的。有朋友問我如何學C++，我會建議他先去找本數據結構書，把裡面的習題全部用C++做一遍，然後再去看《Effective C++》。myan經常說「要在學習初期養成好習慣」，我對此頗不以為然。
個人認為，《Essential C++》適合作教材，《C++ Primer》適合作參考書，《Effective C++》適合作課外讀物。

惡魔：很後悔當初買了《C++ Primer》。因為從我個人角度來看，它的功能效用基本是和《The C++ Programming Language》重合。當然對於入門來說，它還是很不錯的。但是《C++ Primer》太厚，一來導致看書極其不方便，二來系統學習需要花比較長的時間。對於目前這個越來越快餐化的時代來說，的確有很多不適合的地方，不過可以作為初學者的參考書。現在我以一塊K3 CPU的代價把它借給了別人，希望我那位同事能夠從中得到一些益處。
如果已經具備了C基礎，我建議看國內的書，例如錢能的《 C++大學教程（第二版） 》。(如果沒有C的基礎還是看譚浩強的C語言)。這本書對C講得還算比較清晰，有很多習題值得一做，特別是最後的struct和union兩個部分。其中的一些演算法比較拖沓和繁瑣（比如樹和鏈表的遍歷演算法），讀者可以嘗試修改這些例子，作為最後對C語言的一些總結測試。

夢魘：這個問題讓我想起四五年前的情形。今天對於C++有一點認識的人，多半是從那幾年就開始學C++了。那時根本沒有品牌觀念。從書店裡找一本C++書，如果看著還算明白，就買下來。我記得那時候宛延闓、張國鋒、麥中凡教授的書都受到很高的贊譽。我個人最早的一本C++書是Greg Perry的一本書，今天想起來，其實是一本打著C++旗號的C語言教程。對我作用最大的一本書是國防科技出版社出版的一本書，書名記不得了，作者叫斯蒂芬·布萊哈。
透明：還記得以前曾批評過一本C++書，是北航出的，整本書就沒有出現過class關鍵字。那本書，說穿了其實只是介紹了C語言和iostream庫的用法，根本不能算C++。而當時我常常推薦的一本書是電子科技大學張松梅老師的C++教程。那本書，直到今天來看也沒有太大的問題，唯一的缺憾就是由於年代久遠，許多東西已經過時了。而對於一本技術書籍來說，「過時」是最不可接受的。
總體來說，那時使用C++的人真是在「盲人摸象」。不過這也有好處，就是對C++的很多細節能搞清楚，以後看到經典好書時比較容易理解；當然壞處就是概念不清，甚至都不知道C++和Visual C++、Borland C++到底有什麼不一樣。

夢魘：整個90年代，其實大部分人對於C++的認識都似是而非。一開始是等同於Borland C++，後來是等同於Visual C++和MFC。所以一般來說，打著BC和VC旗號的書賣得很好，人們覺得這就是C++。而我比較幸運，布萊哈的那本書雖然從現在的眼光來看談不上高超，但基本路子是對的。可能是因為原書是給UNIX程序員的培訓教材，所以沒有讓我一開始就形成「C++ == VC++」的認識。
其實一直到1996年，我們那裡搞計算機的都是唯Borland C++馬首是瞻的，到了VC 4.0出來，一下子格局全變了。1997年VC5推出之後，書店裡MFC書鋪天蓋地，學MFC的人，頭抬得都比別人高一些。不過現在看來，那時候大部分的MFC書都是三流貨色。我曾經有一段時間認為，那一批程序員中間有不少被誤導了。根本原因就是相對的封閉。

透明：我覺得一本書的價值有兩方面：第一，教給你實用的技術；第二，促使你去思考。對於一本介紹VC（或者說MFC）使用方法的書，我根本不希望它能促使我有什麼思考，所以我就一定要求它在技術上精益求精完美無瑕。我剛開始用VC的時候，買的第一本書就是潘愛民老師翻譯的《VC技術內幕》（第四版），沒有受到那些「三流貨色」的誤導，應該說是很幸運的。

夢魘：1999年機械工業出版社開始出版「計算機科學叢書」，其中的《Thinking in C++》第一版受到了廣泛的歡迎。其實我一直不認為這本書很出色，雖然拿過一次大獎。然而我們都得承認，這本書在C++書籍領域里第一次建立了品牌觀念，很多初學者開始知道，不是隨便買哪一本都一樣的。再往後就是2000年的《 深入淺出MFC（第二版） 》第二版，以及侯先生在《程序員》上發表的那一篇《C++/OOP大系》，加上整個大環境的變化，品牌觀念深入人心，C++書籍市場終於開始逐漸與世界同步。
回想往事，我的感覺是，那個需要戰戰兢兢選擇入門書的時代已經過去，今天的C++初學者，大可以放心地買口碑好、自己讀起來思路順暢的書，入門不再是太大的問題。還有一些程序員已經學了幾年C++，但看到今天出版的一些新書，感覺比較陌生，這也不是什麼問題。侯先生經常說「凡走過必留下足跡」，所謂「走彎路」，未必不是一件好事。
至於具體的推薦表，就不好一概而論了。總之在我的印象里，《Essential C++》、《C++ Primer》、錢能教授的C++教程，都不錯。甚至有人一上來就看Bjarne Stroustrup的《The C++ Programming Language》，只要他喜歡，也沒什麼不可以。

透明：我同意你的觀點。不管怎麼說，編程是門實踐性非常強的學問。要想對C++對象模型有深入的了解，最好的辦法就是寫一串程序去看結果；要想學會OOP，也只能從項目中學。對於初學者，最好的學習方法就是不停地寫程序，寫真正有用的程序，寫到有問題的時候就去查書，於是自然就會知道哪本書好哪本書不好。不過我們的教育制度能不能讓大學里的學生們有這樣的學習機會，我表示懷疑。
以我的經驗，學C++有兩個門檻：入門和使用。完全看不懂C++，這是一個門檻，但是只要有一本合適的入門書，很快就能跨過。要想真正用上C++，卻不是件很容易的事情。尤其對於學生來說，接觸到的東西多是「玩具」，很難有實戰的機會。所以經常看見有人問「C++到底能做什麼」，這是C++學習中一個比較麻煩的問題。我們都是做了相當長時間的C++程序之後才看到一些真正經典的書，也正是因為走了相當長的彎路之後才知道這些書的經典之所在。所謂彎路，我想也是一種必須的積累。就算一開始就看《Essential C++》和《C++ Primer》，沒有兩三年的時間恐怕還是難有所得。

惡魔：有兩句十分有道理的話，一是我大學的C語言老師說的「寫程序不如說是抄程序」，另一句是一網友說的「好的設計來自借鑒，天才的設計來自剽竊」。對於我這個理性批判主義者來說，這兩句話的確不太適合。但是無論從哪個角度來講，對於初學者來說，剽竊大師的作品是通向成功的最快捷徑。
我個人認為，對於C++的初學者來說，首先要確定自己專業領域內主要使用的特性的方向。因為C++的特性如此眾多，初學者想貪多基本是不可能成功的。C++的編程範式基本可以分為ADT+PP、GP和OO三個方向。對於ADT+PP範式來說，初學者的主要問題不是學習C++，而是學習C的使用。對於這樣的初學者，國內的幾本書還是寫得比較清楚，符合中國人的習慣，比如譚浩強的《C語言教程》、錢能的《C++語言大學教程》。這兩本書我首推第一本，因為這一本我潛心研究了一年，這本書當中很多程序是可以剽竊的，而且可以對這些程序進行加工和提升。比如結構這一章中，它所給出的用struct來實現鏈表、二叉樹的演算法是相當蹩腳的。學習ADT+PP的初學者將這本書揣摩透以後可以嘗試修改這兩個程序。另外這本書的第二版稍微涉及了一些關於「類」的內容。學習ADT+PP的初學者，可以不被OO中的一些專有特性擾亂自己的思路，對於類層次扁平、無繼承、無多態的程序編寫是有很大好處的。

透明：你好象比較推崇國內教授寫的書。現在社會上有種不好的風氣：一捧就捧上天，一貶就貶下地。就好象對待譚教授的書，前幾年是奉為經典，這幾年又有很多人使勁批評。學C++更是有點「崇洋媚外」，總是覺得初學就應該看《Essential C++》。我看這種觀點也是片面的。

惡魔：當然《Essential C++》也值得看看。但是我個人覺得這本書沒有譚浩強的《C語言教程》來得好。主要原因是：第一，C++的所有特性都點到了，但是不深，看了以後會三心二意沒有方向；第二，可以抄襲借鑒的例子太少。《C語言教程》中有很多有趣的問題，比如猴子吃桃、漢諾塔等等，這些例子對於剛剛涉及C/C++語言編程的人來說是學習編程很好的例子。《Essential C++》只能是前兩本書看透以後，作為學習C++特性的一個過渡性的書籍。讓讀者真正領略到什麼是C++的編程、和C編程的不同點在哪裡。

透明：我發現一個很有趣的現象：初學者往往喜歡問「哪本書比較好」，這讓我很是不解。這有點像一個剛學打籃球的人問「王治郅和科比誰比較厲害」。當然科比更厲害一些。但如果你是想學打籃球，這兩個人都非常非常有資格教你，你跟誰學都能學得很強——關鍵不是在於你選哪個老師，而是在於你自己用多少功夫去學。

透明：回到原來話題。學會了C++的語法，能看懂C++代碼之後，必須有些書來指導進階（或者叫指點迷津）。我覺得《設計模式》很好，能夠讓讀者看到一些精妙的用法。不過正如我經常說的，模式帶來的麻煩和好處一樣多，甚至麻煩還要更多。而且，C++本身的問題使得在C++中使用GoF模式愈加麻煩。

夢魘：《Design Patterns》這本書絕對是不可以沒有的，而且中英文版都不可少。最初我看中文版，說實話看不懂，但是也不覺得人家翻譯得不好，所以就想，大概是原文就很難懂，加上自己水平有限。於是總是想著再找幾本patterns的書來看。後來找到幾本書，口碑還不錯，不過水平高下，一比就出來了，還是那本《Design Patterns》最經典，最耐看。英文版出來之後，兩個版本對照看，明白多了。現在覺得，其實就設計模式來講，把這本看明白了就很不錯了，不用再花費很多心思找其他的書。我現在的包里始終夾著這本書，隨身攜帶，有備無患。
至於說設計模式的副作用，和可能帶來的弊端，我的體會也挺多。不過是這樣，我們想一想，究竟什麼情況下設計模式可以用得很好呢？一種是有經驗豐富的人引導，比如要是Robert Martin帶隊，你在某個地方用錯了設計模式，他就會指出來，說這里不對，將來會產生什麼樣的弊端。對於他來說，豐富的實踐經驗足以支持他進行「預測型」設計。但是大部分人沒這個能力，因此我們只好走第二條路和第三條路，就是「試探型」設計和「重構型」設計。遇到一個問題，你覺得用某種模式挺合適的，就大膽地用了，成功是積累經驗，發現不好，出了問題了，只好改回來，那也是積累教訓。這叫做「試探型」。至於重構，應該算是最有組織、成功率最高的工程化方法。先把問題「quick and dirty」地解決了，所有的暗礁都暴露出來，然後再根據實際情況採用合適的模式優化設計。現在XP和UP都高度重視refactory，UP在Elaboration和Construction階段都鼓勵抽出專門的iterations進行重構。所以說如果組織快速的軟體開發，當然比較傾向於這條路——打成功率嘛。

透明：講到重構，我順便說說《Refactoring》這本書的影響。從工程本身的角度來說，你所謂的「重構型設計」是沒有什麼問題的。但中國的開發者（也包括我在內）往往比較沖動，比較容易相信銀彈的存在。曾經有那麼一段時間，我在Java中嘗試過了重構的方法之後，又拿到C++中去嘗試。結果發現，在Java中速度非常快的重構過程，到C++中就被減慢了。究其原因，就是因為C++和Java的約束條件不同。拿著Java中成功的案例直接套C++，不失敗才怪。
所以，我必須說：《Refactoring》這本書很有價值。但對於C++程序員來說，它的價值是讓你思考，思考這種方法的可行性。如果一個C++程序員沒有打算遷移到Java，那麼我必須告訴他：《Refactoring》這本書不是讓你照著它用的，甚至不是讓你去相信它的。對於C++程序員，《Refactoring》全書可以放心相信的只有第13章，其他的部分，都必須非常謹慎地對待。

夢魘：我還要就「試探型」的方法多說兩句，我覺得對於個人發展來講，「試探」也是必不可少的，撞牆不可怕，高水平的人不都是撞出來的嗎？你失敗了一次，就知道這個模式有什麼潛在的問題，下次再用，就會多看幾步，像下棋似的。撞的多了，路數就出來了。
我不知道你們是否有這個感覺：用錯了模式，吃了虧，再回過頭去翻翻《Design Patterns》，看到人家早就指出來這個問題，不過就是那麼幾句話，原來看上去乾巴巴的，現在覺得句句都講到心坎上，GoF的形象馬上就高大起來，還帶著光環，感覺是既興奮又懊悔。

透明：現在回頭來看，我更欣賞myan推薦給我的《Designing Object-Oriented C++ Applications Using Booch Method》。這本書能夠幫助C++程序員理清思路培養習慣，可惜國內沒有引進。相比後來商業味濃厚的UML系列書籍，我覺得這本書對於面向對象的闡釋精闢獨到，至今未有能出其右者。

夢魘：剛才我們兩人都說到Robert Martin，他可是我的榜樣。那本1995年的《Designing Object Oriented C++ Application》，我覺得是每一個C++軟體工程師都應該反復研讀的書。可惜不僅國內沒有引進，在國外的名氣也不大。如果你覺得面向對象的那些道理你好像都明白，可就是一遇到實際問題就使不上勁，那這本書就是你的最佳導師。
提到理清思路，還有一本書不得不提，就是Andrew Koenig的《Ruminations On C++》。每個人都應該問自己，我學了這么多年的C++，究竟什麼是C++最基本的設計理念？遇到問題我第一個直覺是什麼？第一個試探型的解決方案應該具有那些特點？如果你不能給出明確的答案，就應該認真地去讀這本書，讀完了你就有了「主心骨」。

透明：插一句話，談談「推薦書」的問題。入門書基本上是放之四海而皆準的，所以推薦的意義也不大。而入門後的發展方向，每個人不同，這個時候就需要「高人」的指點。舉個例子：我學C++的時候，myan還不認識我，所以也沒有給我推薦書，我還是學過來了，所以即使你當時向我推薦了《Essential C++》或者《C++ Primer》，我也不會太感謝你；但在我認真研究OO的時候，你推薦Robert Martin那本書給我，對我幫助就特別大，而且我從別的地方也很難找到類似的推薦，所以我就很感謝你。
一個程序員，必須有framework的意識，要學會用framework，還要主動去分析framework（在這方面，《Design Patterns》能有一定的幫助）。但是，真正高質量、成氣候的framework的書恐怕也就只有針對MFC的。從這個角度來說，MFC縱有千般不是，C++程序員都非常有必要先去用它、熟悉它、研究它，甚至藉助《深入淺出MFC》這樣的書來剖析它。不然，很難有framework的意識和感覺。
當然，另一個framework也很好，那就是STL。不管用不用MFC、STL，對這兩個東西的掌握和理解都是極有幫助的。最近我又在看《深入淺出MFC》，雖然已經不用MFC編程了，但幫助是一定有的。

夢魘：MFC和STL方面，我還是比較推崇侯先生的兩本書《深入淺出MFC》和《STL源碼解析》。
《深入淺出MFC》這本書，名氣自然是大得不得了，不過也有不少人批評。其實書也沒有十全十美的，批評當然是少不了的，不過有的時候我看到有人評論這本書，把它跟Inside VC相比，真的是牛頭不對馬嘴。
你剛才其實說得很對，程序員應該有一點framework意識。而這本《深入淺出MFC》與其說是在講MFC編程，不如說通篇是在拿MFC為例分析Application Framework的架構和脈絡。所以無論你對於MFC本身是什麼態度，這本書對每一個C++程序員都有很大的益處。

透明：是的。《VC技術內幕》會告訴你「DYNAMIC_CREATE這個宏怎麼用」，《深入淺出MFC》則告訴你「DYNAMIC_CREATE這個宏是怎麼實現的」。所以，如果你只需要在VC下寫一些小應用程序，《深入淺出MFC》的價值並不太大；但是，如果你需要設計一個稍微大一點的東西（不一定是framework），MFC的設計思想就會有所幫助。

夢魘：另外，我覺得對於MFC也應該有一個公允的評價。過去是吹捧得天上有地下無，書店裡鋪天蓋地都是MFC的書，搞得大家只知有MFC，不知有C++，甚至直到現在還有人問：「我是學MFC呢，還是學C++？VC++是不是比C++更高級的語言？」MFC成了一尊神像，阻礙了人們的視線。所以得把它從神壇上拉下來。這就是過去一兩年有很多人，包括我在內批評MFC的一個目的。可是現在大家視野開闊了，.NET也出來了，MFC不再是神像了，少數人就開始以貶損MFC為樂了。我覺得這種態度是不對的。
什麼叫好的框架？我覺得在十幾年的時間能夠象MFC這樣保持穩定並且不斷進步的框架就是好的框架。可能我們在一些具體的設計問題上有不同看法，覺得「這個地方這么設計不是更漂亮嗎？」很多時候是的，但是這不重要，重要的是MFC成熟穩定、有十幾年的成功經驗，這是最了不起的東西。
另外一點，MFC中間包括著學習Win32 API編程的最佳資料。這是除了其framework方面之外的另一個亮點。我現在使用Win32 API開發，但是經常參考MFC的源代碼，收獲很大。

透明：STL方面，我對於剖析它的源代碼興趣並不大，畢竟裡面源代碼多是演算法問題。所以，《STL源碼剖析》我也只是隨便翻翻就束之高閣了。我覺得這本書用來做計算機系的數據結構和演算法教材不錯，不知道有沒有老師樂意這樣做。
對於STL，我的態度一向都是「應用至上」。不過，我一直認為SGI STL本身就是一本精彩的書，一本數據結構和演算法的經典參考書，同時也是泛型技術的參考書。想知道一個演算法是如何實現的，看看STL源代碼就行；想知道如何使用type traits，STL源代碼裡面也有例子。看別人寫的書，總覺得隔著一層紗，有點撓不到癢處的感覺。SGI STL的代碼寫得非常漂亮，一個C++程序員如果不看看這本書，實在是可惜。

夢魘：至於STL，除了《STL源碼解析》之外，我舉賢不避親，強烈推薦侯先生與我合譯的那本《The C++ Standard Library》。這本書質量之高是無需懷疑的。我現在手邊常備此書，隨時查閱，對我幫助很大。

透明：C++和Java相比，最大的優勢就是它沒有一個專門的公司來管它，最大的弱點也是它沒有一個專門的公司來管它。Java程序員在學會簡單的語法之後，立刻進入SUN提供的framework，一邊用這個現成的framework做實際開發，一邊在開發過程中繼續學習Java一些幽深的特性。而這個時候，C++程序員恐怕還在問「VC和BCB哪個好」呢。這無疑是浪費時間。

夢魘：剛才你說Java和C++的優劣，這個話題已經成了我們這個年代永不消失的聲波了。我也不想再談這個。不過有一點我得說清楚：現在我們很多用C++的人吃了不少苦頭，探過脖子去看看Java，覺得它真是太可愛了，這種印象是不準確的。另外，Java也不簡單，而且會越來越龐大復雜。在很多場合，Java還不具有競爭力。至於將來如何，我看有些Java愛好者也過分樂觀了，似乎計算機科學界幾十年解決不了的問題都可以借著Java的東風解決掉，恐怕沒那麼容易。

透明：那當然。我再次強調：No Silver Bullet。讀書很重要，但古人說「行萬里路，讀萬卷書」，還是把「行路」放在「讀書」前面。尤其對於技術書籍，如果它不能幫我解決問題、不能給我帶來非常實際的利益，那麼我是不會去讀它的。惡魔說得對，我們這個社會很快餐，我們這個行業尤其很快餐，我們也只能努力適應它。
另外,站長團上有產品團購,便宜有保證

❺ 零基礎自學c語言需要看什麼書

零基礎自學c語言需要看什麼書
其實具體看哪一本書並不重要，你可以看大學教材，但是重要的是要堅持，而且這個光看是看不會的，要自己動手多多實踐。

❻ C++演算法求精，看看誰的演算法最優

程序員》推薦C++ 圖書三人談

主持人：熊節（透明），《程序員》雜志編輯，C-View成員
嘉 賓：孟岩（夢魘）,聯想公司掌上設備事業部應用開發處任職，C-View成員。與侯捷先生合譯《C++ Standard Library》一書
金尹（惡魔），上海天宇公司CTO，在《程序員》連載有「自由與繁榮的國度」系列文章

透明：「學C++用哪本書入門」，這是被問得最多的一個問題。但是哪一本書是最好的入門書？似乎很難找到答案。《C++ Primer》太厚，《Effective C++》對讀者要求比較高，《Essential C++》又常常被批評為「太淺」。
其實說穿了：no silver bullet。想從一本書學會C++，那是不可能的。有朋友問我如何學C++，我會建議他先去找本數據結構書，把裡面的習題全部用C++做一遍，然後再去看《Effective C++》。myan經常說「要在學習初期養成好習慣」，我對此頗不以為然。
個人認為，《Essential C++》適合作教材，《C++ Primer》適合作參考書，《Effective C++》適合作課外讀物。

惡魔：很後悔當初買了《C++ Primer》。因為從我個人角度來看，它的功能效用基本是和《The C++ Programming Language》重合。當然對於入門來說，它還是很不錯的。但是《C++ Primer》太厚，一來導致看書極其不方便，二來系統學習需要花比較長的時間。對於目前這個越來越快餐化的時代來說，的確有很多不適合的地方，不過可以作為初學者的參考書。現在我以一塊K3 CPU的代價把它借給了別人，希望我那位同事能夠從中得到一些益處。
如果已經具備了C基礎，我建議看國內的書，例如錢能的《 C++大學教程（第二版） 》。(如果沒有C的基礎還是看譚浩強的C語言)。這本書對C講得還算比較清晰，有很多習題值得一做，特別是最後的struct和union兩個部分。其中的一些演算法比較拖沓和繁瑣（比如樹和鏈表的遍歷演算法），讀者可以嘗試修改這些例子，作為最後對C語言的一些總結測試。

夢魘：這個問題讓我想起四五年前的情形。今天對於C++有一點認識的人，多半是從那幾年就開始學C++了。那時根本沒有品牌觀念。從書店裡找一本C++書，如果看著還算明白，就買下來。我記得那時候宛延闓、張國鋒、麥中凡教授的書都受到很高的贊譽。我個人最早的一本C++書是Greg Perry的一本書，今天想起來，其實是一本打著C++旗號的C語言教程。對我作用最大的一本書是國防科技出版社出版的一本書，書名記不得了，作者叫斯蒂芬·布萊哈。
透明：還記得以前曾批評過一本C++書，是北航出的，整本書就沒有出現過class關鍵字。那本書，說穿了其實只是介紹了C語言和iostream庫的用法，根本不能算C++。而當時我常常推薦的一本書是電子科技大學張松梅老師的C++教程。那本書，直到今天來看也沒有太大的問題，唯一的缺憾就是由於年代久遠，許多東西已經過時了。而對於一本技術書籍來說，「過時」是最不可接受的。
總體來說，那時使用C++的人真是在「盲人摸象」。不過這也有好處，就是對C++的很多細節能搞清楚，以後看到經典好書時比較容易理解；當然壞處就是概念不清，甚至都不知道C++和Visual C++、Borland C++到底有什麼不一樣。

夢魘：整個90年代，其實大部分人對於C++的認識都似是而非。一開始是等同於Borland C++，後來是等同於Visual C++和MFC。所以一般來說，打著BC和VC旗號的書賣得很好，人們覺得這就是C++。而我比較幸運，布萊哈的那本書雖然從現在的眼光來看談不上高超，但基本路子是對的。可能是因為原書是給UNIX程序員的培訓教材，所以沒有讓我一開始就形成「C++ == VC++」的認識。
其實一直到1996年，我們那裡搞計算機的都是唯Borland C++馬首是瞻的，到了VC 4.0出來，一下子格局全變了。1997年VC5推出之後，書店裡MFC書鋪天蓋地，學MFC的人，頭抬得都比別人高一些。不過現在看來，那時候大部分的MFC書都是三流貨色。我曾經有一段時間認為，那一批程序員中間有不少被誤導了。根本原因就是相對的封閉。

透明：我覺得一本書的價值有兩方面：第一，教給你實用的技術；第二，促使你去思考。對於一本介紹VC（或者說MFC）使用方法的書，我根本不希望它能促使我有什麼思考，所以我就一定要求它在技術上精益求精完美無瑕。我剛開始用VC的時候，買的第一本書就是潘愛民老師翻譯的《VC技術內幕》（第四版），沒有受到那些「三流貨色」的誤導，應該說是很幸運的。

夢魘：1999年機械工業出版社開始出版「計算機科學叢書」，其中的《Thinking in C++》第一版受到了廣泛的歡迎。其實我一直不認為這本書很出色，雖然拿過一次大獎。然而我們都得承認，這本書在C++書籍領域里第一次建立了品牌觀念，很多初學者開始知道，不是隨便買哪一本都一樣的。再往後就是2000年的《 深入淺出MFC（第二版） 》第二版，以及侯先生在《程序員》上發表的那一篇《C++/OOP大系》，加上整個大環境的變化，品牌觀念深入人心，C++書籍市場終於開始逐漸與世界同步。
回想往事，我的感覺是，那個需要戰戰兢兢選擇入門書的時代已經過去，今天的C++初學者，大可以放心地買口碑好、自己讀起來思路順暢的書，入門不再是太大的問題。還有一些程序員已經學了幾年C++，但看到今天出版的一些新書，感覺比較陌生，這也不是什麼問題。侯先生經常說「凡走過必留下足跡」，所謂「走彎路」，未必不是一件好事。
至於具體的推薦表，就不好一概而論了。總之在我的印象里，《Essential C++》、《C++ Primer》、錢能教授的C++教程，都不錯。甚至有人一上來就看Bjarne Stroustrup的《The C++ Programming Language》，只要他喜歡，也沒什麼不可以。

透明：我同意你的觀點。不管怎麼說，編程是門實踐性非常強的學問。要想對C++對象模型有深入的了解，最好的辦法就是寫一串程序去看結果；要想學會OOP，也只能從項目中學。對於初學者，最好的學習方法就是不停地寫程序，寫真正有用的程序，寫到有問題的時候就去查書，於是自然就會知道哪本書好哪本書不好。不過我們的教育制度能不能讓大學里的學生們有這樣的學習機會，我表示懷疑。
以我的經驗，學C++有兩個門檻：入門和使用。完全看不懂C++，這是一個門檻，但是只要有一本合適的入門書，很快就能跨過。要想真正用上C++，卻不是件很容易的事情。尤其對於學生來說，接觸到的東西多是「玩具」，很難有實戰的機會。所以經常看見有人問「C++到底能做什麼」，這是C++學習中一個比較麻煩的問題。我們都是做了相當長時間的C++程序之後才看到一些真正經典的書，也正是因為走了相當長的彎路之後才知道這些書的經典之所在。所謂彎路，我想也是一種必須的積累。就算一開始就看《Essential C++》和《C++ Primer》，沒有兩三年的時間恐怕還是難有所得。

惡魔：有兩句十分有道理的話，一是我大學的C語言老師說的「寫程序不如說是抄程序」，另一句是一網友說的「好的設計來自借鑒，天才的設計來自剽竊」。對於我這個理性批判主義者來說，這兩句話的確不太適合。但是無論從哪個角度來講，對於初學者來說，剽竊大師的作品是通向成功的最快捷徑。
我個人認為，對於C++的初學者來說，首先要確定自己專業領域內主要使用的特性的方向。因為C++的特性如此眾多，初學者想貪多基本是不可能成功的。C++的編程範式基本可以分為ADT+PP、GP和OO三個方向。對於ADT+PP範式來說，初學者的主要問題不是學習C++，而是學習C的使用。對於這樣的初學者，國內的幾本書還是寫得比較清楚，符合中國人的習慣，比如譚浩強的《C語言教程》、錢能的《C++語言大學教程》。這兩本書我首推第一本，因為這一本我潛心研究了一年，這本書當中很多程序是可以剽竊的，而且可以對這些程序進行加工和提升。比如結構這一章中，它所給出的用struct來實現鏈表、二叉樹的演算法是相當蹩腳的。學習ADT+PP的初學者將這本書揣摩透以後可以嘗試修改這兩個程序。另外這本書的第二版稍微涉及了一些關於「類」的內容。學習ADT+PP的初學者，可以不被OO中的一些專有特性擾亂自己的思路，對於類層次扁平、無繼承、無多態的程序編寫是有很大好處的。

透明：你好象比較推崇國內教授寫的書。現在社會上有種不好的風氣：一捧就捧上天，一貶就貶下地。就好象對待譚教授的書，前幾年是奉為經典，這幾年又有很多人使勁批評。學C++更是有點「崇洋媚外」，總是覺得初學就應該看《Essential C++》。我看這種觀點也是片面的。

惡魔：當然《Essential C++》也值得看看。但是我個人覺得這本書沒有譚浩強的《C語言教程》來得好。主要原因是：第一，C++的所有特性都點到了，但是不深，看了以後會三心二意沒有方向；第二，可以抄襲借鑒的例子太少。《C語言教程》中有很多有趣的問題，比如猴子吃桃、漢諾塔等等，這些例子對於剛剛涉及C/C++語言編程的人來說是學習編程很好的例子。《Essential C++》只能是前兩本書看透以後，作為學習C++特性的一個過渡性的書籍。讓讀者真正領略到什麼是C++的編程、和C編程的不同點在哪裡。

透明：我發現一個很有趣的現象：初學者往往喜歡問「哪本書比較好」，這讓我很是不解。這有點像一個剛學打籃球的人問「王治郅和科比誰比較厲害」。當然科比更厲害一些。但如果你是想學打籃球，這兩個人都非常非常有資格教你，你跟誰學都能學得很強——關鍵不是在於你選哪個老師，而是在於你自己用多少功夫去學。

透明：回到原來話題。學會了C++的語法，能看懂C++代碼之後，必須有些書來指導進階（或者叫指點迷津）。我覺得《設計模式》很好，能夠讓讀者看到一些精妙的用法。不過正如我經常說的，模式帶來的麻煩和好處一樣多，甚至麻煩還要更多。而且，C++本身的問題使得在C++中使用GoF模式愈加麻煩。

夢魘：《Design Patterns》這本書絕對是不可以沒有的，而且中英文版都不可少。最初我看中文版，說實話看不懂，但是也不覺得人家翻譯得不好，所以就想，大概是原文就很難懂，加上自己水平有限。於是總是想著再找幾本patterns的書來看。後來找到幾本書，口碑還不錯，不過水平高下，一比就出來了，還是那本《Design Patterns》最經典，最耐看。英文版出來之後，兩個版本對照看，明白多了。現在覺得，其實就設計模式來講，把這本看明白了就很不錯了，不用再花費很多心思找其他的書。我現在的包里始終夾著這本書，隨身攜帶，有備無患。
至於說設計模式的副作用，和可能帶來的弊端，我的體會也挺多。不過是這樣，我們想一想，究竟什麼情況下設計模式可以用得很好呢？一種是有經驗豐富的人引導，比如要是Robert Martin帶隊，你在某個地方用錯了設計模式，他就會指出來，說這里不對，將來會產生什麼樣的弊端。對於他來說，豐富的實踐經驗足以支持他進行「預測型」設計。但是大部分人沒這個能力，因此我們只好走第二條路和第三條路，就是「試探型」設計和「重構型」設計。遇到一個問題，你覺得用某種模式挺合適的，就大膽地用了，成功是積累經驗，發現不好，出了問題了，只好改回來，那也是積累教訓。這叫做「試探型」。至於重構，應該算是最有組織、成功率最高的工程化方法。先把問題「quick and dirty」地解決了，所有的暗礁都暴露出來，然後再根據實際情況採用合適的模式優化設計。現在XP和UP都高度重視refactory，UP在Elaboration和Construction階段都鼓勵抽出專門的iterations進行重構。所以說如果組織快速的軟體開發，當然比較傾向於這條路——打成功率嘛。

透明：講到重構，我順便說說《Refactoring》這本書的影響。從工程本身的角度來說，你所謂的「重構型設計」是沒有什麼問題的。但中國的開發者（也包括我在內）往往比較沖動，比較容易相信銀彈的存在。曾經有那麼一段時間，我在Java中嘗試過了重構的方法之後，又拿到C++中去嘗試。結果發現，在Java中速度非常快的重構過程，到C++中就被減慢了。究其原因，就是因為C++和Java的約束條件不同。拿著Java中成功的案例直接套C++，不失敗才怪。
所以，我必須說：《Refactoring》這本書很有價值。但對於C++程序員來說，它的價值是讓你思考，思考這種方法的可行性。如果一個C++程序員沒有打算遷移到Java，那麼我必須告訴他：《Refactoring》這本書不是讓你照著它用的，甚至不是讓你去相信它的。對於C++程序員，《Refactoring》全書可以放心相信的只有第13章，其他的部分，都必須非常謹慎地對待。

夢魘：我還要就「試探型」的方法多說兩句，我覺得對於個人發展來講，「試探」也是必不可少的，撞牆不可怕，高水平的人不都是撞出來的嗎？你失敗了一次，就知道這個模式有什麼潛在的問題，下次再用，就會多看幾步，像下棋似的。撞的多了，路數就出來了。
我不知道你們是否有這個感覺：用錯了模式，吃了虧，再回過頭去翻翻《Design Patterns》，看到人家早就指出來這個問題，不過就是那麼幾句話，原來看上去乾巴巴的，現在覺得句句都講到心坎上，GoF的形象馬上就高大起來，還帶著光環，感覺是既興奮又懊悔。

透明：現在回頭來看，我更欣賞myan推薦給我的《Designing Object-Oriented C++ Applications Using Booch Method》。這本書能夠幫助C++程序員理清思路培養習慣，可惜國內沒有引進。相比後來商業味濃厚的UML系列書籍，我覺得這本書對於面向對象的闡釋精闢獨到，至今未有能出其右者。

夢魘：剛才我們兩人都說到Robert Martin，他可是我的榜樣。那本1995年的《Designing Object Oriented C++ Application》，我覺得是每一個C++軟體工程師都應該反復研讀的書。可惜不僅國內沒有引進，在國外的名氣也不大。如果你覺得面向對象的那些道理你好像都明白，可就是一遇到實際問題就使不上勁，那這本書就是你的最佳導師。
提到理清思路，還有一本書不得不提，就是Andrew Koenig的《Ruminations On C++》。每個人都應該問自己，我學了這么多年的C++，究竟什麼是C++最基本的設計理念？遇到問題我第一個直覺是什麼？第一個試探型的解決方案應該具有那些特點？如果你不能給出明確的答案，就應該認真地去讀這本書，讀完了你就有了「主心骨」。

透明：插一句話，談談「推薦書」的問題。入門書基本上是放之四海而皆準的，所以推薦的意義也不大。而入門後的發展方向，每個人不同，這個時候就需要「高人」的指點。舉個例子：我學C++的時候，myan還不認識我，所以也沒有給我推薦書，我還是學過來了，所以即使你當時向我推薦了《Essential C++》或者《C++ Primer》，我也不會太感謝你；但在我認真研究OO的時候，你推薦Robert Martin那本書給我，對我幫助就特別大，而且我從別的地方也很難找到類似的推薦，所以我就很感謝你。
一個程序員，必須有framework的意識，要學會用framework，還要主動去分析framework（在這方面，《Design Patterns》能有一定的幫助）。但是，真正高質量、成氣候的framework的書恐怕也就只有針對MFC的。從這個角度來說，MFC縱有千般不是，C++程序員都非常有必要先去用它、熟悉它、研究它，甚至藉助《深入淺出MFC》這樣的書來剖析它。不然，很難有framework的意識和感覺。
當然，另一個framework也很好，那就是STL。不管用不用MFC、STL，對這兩個東西的掌握和理解都是極有幫助的。最近我又在看《深入淺出MFC》，雖然已經不用MFC編程了，但幫助是一定有的。

夢魘：MFC和STL方面，我還是比較推崇侯先生的兩本書《深入淺出MFC》和《STL源碼解析》。
《深入淺出MFC》這本書，名氣自然是大得不得了，不過也有不少人批評。其實書也沒有十全十美的，批評當然是少不了的，不過有的時候我看到有人評論這本書，把它跟Inside VC相比，真的是牛頭不對馬嘴。
你剛才其實說得很對，程序員應該有一點framework意識。而這本《深入淺出MFC》與其說是在講MFC編程，不如說通篇是在拿MFC為例分析Application Framework的架構和脈絡。所以無論你對於MFC本身是什麼態度，這本書對每一個C++程序員都有很大的益處。

透明：是的。《VC技術內幕》會告訴你「DYNAMIC_CREATE這個宏怎麼用」，《深入淺出MFC》則告訴你「DYNAMIC_CREATE這個宏是怎麼實現的」。所以，如果你只需要在VC下寫一些小應用程序，《深入淺出MFC》的價值並不太大；但是，如果你需要設計一個稍微大一點的東西（不一定是framework），MFC的設計思想就會有所幫助。

夢魘：另外，我覺得對於MFC也應該有一個公允的評價。過去是吹捧得天上有地下無，書店裡鋪天蓋地都是MFC的書，搞得大家只知有MFC，不知有C++，甚至直到現在還有人問：「我是學MFC呢，還是學C++？VC++是不是比C++更高級的語言？」MFC成了一尊神像，阻礙了人們的視線。所以得把它從神壇上拉下來。這就是過去一兩年有很多人，包括我在內批評MFC的一個目的。可是現在大家視野開闊了，.NET也出來了，MFC不再是神像了，少數人就開始以貶損MFC為樂了。我覺得這種態度是不對的。
什麼叫好的框架？我覺得在十幾年的時間能夠象MFC這樣保持穩定並且不斷進步的框架就是好的框架。可能我們在一些具體的設計問題上有不同看法，覺得「這個地方這么設計不是更漂亮嗎？」很多時候是的，但是這不重要，重要的是MFC成熟穩定、有十幾年的成功經驗，這是最了不起的東西。
另外一點，MFC中間包括著學習Win32 API編程的最佳資料。這是除了其framework方面之外的另一個亮點。我現在使用Win32 API開發，但是經常參考MFC的源代碼，收獲很大。

透明：STL方面，我對於剖析它的源代碼興趣並不大，畢竟裡面源代碼多是演算法問題。所以，《STL源碼剖析》我也只是隨便翻翻就束之高閣了。我覺得這本書用來做計算機系的數據結構和演算法教材不錯，不知道有沒有老師樂意這樣做。
對於STL，我的態度一向都是「應用至上」。不過，我一直認為SGI STL本身就是一本精彩的書，一本數據結構和演算法的經典參考書，同時也是泛型技術的參考書。想知道一個演算法是如何實現的，看看STL源代碼就行；想知道如何使用type traits，STL源代碼裡面也有例子。看別人寫的書，總覺得隔著一層紗，有點撓不到癢處的感覺。SGI STL的代碼寫得非常漂亮，一個C++程序員如果不看看這本書，實在是可惜。

夢魘：至於STL，除了《STL源碼解析》之外，我舉賢不避親，強烈推薦侯先生與我合譯的那本《The C++ Standard Library》。這本書質量之高是無需懷疑的。我現在手邊常備此書，隨時查閱，對我幫助很大。

透明：C++和Java相比，最大的優勢就是它沒有一個專門的公司來管它，最大的弱點也是它沒有一個專門的公司來管它。Java程序員在學會簡單的語法之後，立刻進入SUN提供的framework，一邊用這個現成的framework做實際開發，一邊在開發過程中繼續學習Java一些幽深的特性。而這個時候，C++程序員恐怕還在問「VC和BCB哪個好」呢。這無疑是浪費時間。

夢魘：剛才你說Java和C++的優劣，這個話題已經成了我們這個年代永不消失的聲波了。我也不想再談這個。不過有一點我得說清楚：現在我們很多用C++的人吃了不少苦頭，探過脖子去看看Java，覺得它真是太可愛了，這種印象是不準確的。另外，Java也不簡單，而且會越來越龐大復雜。在很多場合，Java還不具有競爭力。至於將來如何，我看有些Java愛好者也過分樂觀了，似乎計算機科學界幾十年解決不了的問題都可以借著Java的東風解決掉，恐怕沒那麼容易。

透明：那當然。我再次強調：No Silver Bullet。讀書很重要，但古人說「行萬里路，讀萬卷書」，還是把「行路」放在「讀書」前面。尤其對於技術書籍，如果它不能幫我解決問題、不能給我帶來非常實際的利益，那麼我是不會去讀它的。惡魔說得對，我們這個社會很快餐，我們這個行業尤其很快餐，我們也只能努力適應它。

❼ 什麼是專業的程序員

看了孟岩的文章 《程序員必須走向專業化》 ，有點感想。 真正專業的軟體工程師, 企業寧要專業的工程師，不要不專業的牛人。專業性保證了一個程序員的技能和工作能夠為組織帶來效益，而他們只會為這種效益付酬，不會出於對大牛的敬仰之情而主動上繳貢銀。而且，他們也相信，只要一個人專業化程度足夠，技術和經驗上的不足是容易在實踐中彌補的。 記得近兩年有一句很流行：老大, 咱沒這么干過，咱不專業啊 專業的企業精神 （做事高效負責，規范化的價值觀和知識體系，規范化的工作習慣和職業紀律，職業化的工作作風和流程）2.編程很專業（技術精湛，經驗豐富，有獨立分析問題和解決問題的能力）3.做事很專業（善於溝通，不論是和客戶、同事、項目經理、新手，還是老手，樂於和他人合作，具有團隊精神） 與之相對應的就是不專業的程序員：1.無企業精神（個人主義嚴重，覺得自己技術特牛，貢獻特大，認為企業給的薪水少，幹活不該賣力，項目經理安排的任務故意拖拉不服從，上班很晚到等）2.編程不專業（沒寫過幾行代碼，沒做過什麼大系統，就認為自己技術特精湛，其實寫的代碼卻不堪一擊；沒工作幾年就認為經驗特豐富，沒碰到過多少客戶和生產上的具體問題就認為有豐富的分析問題和解決問題的能力）3.做事不專業（難於溝通和合作，沒有團隊精神和集體精神，不是本著解決問題的態度和學習提高的態度，而是本著耍弄技巧、高人一等甚至刁難別人的態度，和客戶沒溝通點、和項目經理溝通陰奉陽違，對新手好為人師，對老手不屑一顧等等） 幾乎每個團隊都有幾個專業的程序員，即主程序員，也有很多不專業或即將專業的程序員；有剛畢業朝氣蓬勃的白紙小伙，也有業務經驗豐富但默默無聞的老黃牛，有滿身帶刺的所謂技術牛人，也有不大伸張的真正牛人；項目經理如何管理和激勵團隊成員，揚長避短，使團隊發揮最大戰鬥力，如何幫助團隊成員成長，這是項目經理需要思考的問題。 而從程序員自身來說，則應當向專業化的方向努力，無論你的職業方向是管理、技術、還是技術管理，這些都是必須的。因為說到底，只有你做的專業，只有你做出來的東西專業，才能讓人信服。附：很多人談到職業素養問題，《程序員》雜志 刊登的程序員職業素養：1. 學習和分析能力 。每個團隊都在成長，作為程序員這個群體就更需要與時俱進。尤其是在開發這個知識日新月異的行業里，同時分析能力是必不可少的。像本案例中，如果沒有在充分了解客戶需求的基礎上的精準分析，很難想像最後的結果。；（調查中71.15%人認為，學習能力是程序員基本能力中比較重要的一條。另外，此次調查中57.69%的被訪者認為，在技術方面有不同意見時，處理妥當的程序員必要的修煉之一。相信這個案例為我們提供了新的思路。2. 與內外保持良好溝通，永遠是成功的保證 。及時匯報、溝通進展也可以在第一時間發現自己的偏差。在改bug問題上，有些小bug ，程序員可能比較容易就修改了，但有些比較難修改的bug ，如果自己解決不了，應該像同事或者專家請教，甚至組織小組討論，但有些程序員處理這種情況時，往往是自己琢磨半天，改不了，然後就放那去做別的事情了，等過幾天項目經理問起來時，才承認自己改不了，這種現象應該最大程度地避免。畢竟，相差一度兩條線頂點的距離會在不限延伸後相差不限大。（59.62%的被訪者認為匯報項目進展時明確及時是程序員內在修煉的重要組成）3.產品意識 。良好的產品意識可以大幅度提高開發效率。某次產品改版中界面都重新修改過了，因為有2個程序員專門負責編程匹配部分，而其中一個就非常具有產品意識，他用 .NET把UI原形都畫了出來，在公司內部組織討論，讓最後的客戶環境和界面都非常優秀。4.團隊意識 。作為一個新人要向老人請教學習，作為一個老人要把自己的心得、收獲、技能等與新人分享，也就是要帶新人。知識的分享是知識學習中一個最有效的方法，尤其是在程序員這個行當里；5. 對於編碼規范和文檔規劃是毫無疑問必須要遵守的 。（此次參加調查的程序員中有80.77%認為編碼規范是程序員內在修煉的畢選項。、68.59%認為文檔規范是修煉的必要內容。）

❽ 請大家幫我開解一下

作為一個程序員，要學好編程，先學好學精c語言，c語言博大精深。學好c語言能夠深入理解程序深層次的東西。
到了商業領域，企業為了軟體開發效率和節約成本，所以用java。而且java那麼多API，集成度高，不學c語言而直接去學java，會造成知其然而不知其所以然。我個人認為java等一些高級語言會墮化人的編程能力。

❾ 編程之美的作品評價

（1）的確是好書，不同於演算法導論和程序設計藝術之類的書（比較抽象），結合很多比較現實易於形象化的題目，大開眼界。每天做兩道題目，感覺挺有收獲的。
——互動網讀者superzxt
（2）這本書對於學生求職還是很有幫助的，通過做題可以先感受一下筆試面試氣氛，拓寬自己的解題思路，從而有助於找到一份不錯的工作。強烈推薦大家對每一道題目都好好揣摩揣摩，必能受益良多。
——互動網讀者cx_flying
（3）這本書表面上是講解演算法，實際上體現了一種面對困難、解決問題的心態……個人還是挺喜歡這類書的，把編程人性化了……
——互動網讀者拓荒者
（4）……這本書更大的作用在於——給你一個有趣的題目，讓你自己去思考，思考出來後再對照它給出的解法，看看你是否做對了。在這個過程中，你學會了作為一個程序員最重要的東西——獨立思考的能力，而不是碰到問題就在網上到處找代碼片段，盲目拷貝已有的解決方案。
——互動網讀者CoolJie2001
（5）買這本書是因為看到這本書名字的前四個字，而非後面幾個字。看著書的封面，樸素簡單的設計，處處透出清新之美。
隨著軟體產業的迅速發展，各種高級編程語言鋪天蓋地席捲而來，軟體開發變得單調而枯燥，而編程本身的樂趣如今卻很難在身邊找到。這本書正是迎合了我的想法，編程本身應該非常有樂趣，通過巧妙的思考，尋求解決問題的方法。《編程之美》放在案前，每有倦意，品杯香茶，翻開幾頁，感受久違的古色古香，沉浸在美妙的思考中，別有一翻滋味~~
——當當網讀者nuaapjy
（6）之前對演算法的印象是晦澀難懂，每每總是望而卻步，提不起來興趣去研究演算法，讀了《編程之美》中的幾個演算法，有一種豁然開朗的感覺，原來演算法也可以講的這么生動有趣，這么吸引人。《編程之美》中的演算法以實例開題，循序漸進的解決問題，一步步去剖析演算法的本質，挖掘和發散演算法功效，進而去淋漓盡致的體現演算法的美妙！
——當當網讀者蘿卜蘿卜閃金光
（7）一本編程的課外讀物，引發編程興趣的好書。
——當當網讀者tiangu0120
（8）此書重要的是開拓思路，有一定基礎的朋友看了這個，就會有一種意猶未盡的感覺，「原來還可以這么玩啊」的想法。
——卓越網讀者yc_andy1009
（9）剛剛讀完這本書，感覺不錯，啟發很大，這是我繼讀完《演算法導論》以來發現比較好的一本書，推薦對演算法以及對大公司的面試題有興趣的人去看看。
——卓越網讀者lironghua
（10）演算法是計算機程序設計的靈魂，是每個計算機專業的學生和從業人員必須具備的基本素質之一。微軟把一些看似簡單，實則蘊含深刻內涵的演算法題目作為面試的重要內容，是經過深思熟慮了的。
——網友Sswv
（11）《編程之美》中這些謎題考察、鍛煉的是扎實、嚴密和具有創造性的思考能力，面對問題有條不紊的分析能力，和不斷深入、刨根問底的精神。毫無疑問，這些素質，都是軟體工程師身上最寶貴的東西。
——《程序員》雜志技術主編孟岩
（12）隨著軟體產業的迅速發展，各種高級編程語言鋪天蓋地席捲而來，軟體開發變得單調而枯燥，而編程本身的樂趣如今卻很難在身邊找到。《編程之美》正是迎合了我的想法，編程本身應該非常有樂趣，通過巧妙的思考，尋求解決問題的方法。
——當當網讀者nuaapjy
（13）我招人的時候找了《編程之美》上面的題目作參考，效果還不錯。裡面描述的演算法很有意思。
——當當網讀者beikerray119
（14）工程師的驕傲，在於創造。編程的樂趣也在於探索。當我們不僅愛玩電腦，會玩電腦，也嘗試著用電腦去解決實際的問題並獲得成功的時候，那種自我肯定的快樂是一般途徑所體會不到的。
何為編程之美？巧妙的思路，簡明的演算法，嚴謹的數學分析——這些綜合起來就是編程之美。
——網友Ultra

❿ 推薦學習c++ stl 使用方法的書籍

C++標准程序庫:自修教程與參考手冊
Nicolai M.Josuttis (作者), 侯捷 (譯者), 孟岩 (譯者)

這是一本非常好的書，因為它的知識是非常詳細的，作者的思想非常好，全書沒有一點空話、廢話，每一點知識都可以讓我們思考學習。是站在讀者的角度寫的這本書。
此書是學習C++標准程序庫的必讀教材。

如果你初學C++，不要選擇這本書。
應該先讀一下primer或者The c++ programming language

如果你對C++有了一定的理解，對面向對象變成有基本的掌握。或者試著自己實現過string，vector等容器，那麼讀這本書將對你大有裨益。

如果你是高級程序員，那麼這本書無疑可以成為你STL參考書的首選。