close
 | 作者：（美）薩特（Sutter,H.） 著，劉未鵬 譯 出版社：人民郵電出版社 出版日期： ISBN：7115142254 字數：408000 印次：1 版次：1 紙張：膠版紙 |
內容提要
本書中，C++大師Herb Sutter通過40個編程問題，不僅使讀者“知其然”，更要“知其所以然”，幫助程序設計人員在軟件中尋找恰到好處的折衷，即討論如何在開銷和功能性之間、優雅跟可維護性之間、靈活性與過分靈活之間尋找完美的平衡點。本書是圍繞實際問題及其解決方案展開論述的，對一些至關重要的C++細節和相互關系提出了新的見解，爲當今關鍵的C++編程技術（如泛型編程、STL、異常安全等）提供了新的策略。本書的目標是讓讀者在設計、架構和編碼過程中保持良好的風格，從而使編寫的C++軟件更健壯、更高效。本書適合各個層次的C++程序員閱讀。
作者簡介
Herb Sutter ISO C++標准委員會主席，C++ Users Journal雜志特邀編輯和專欄作家。他目前在微軟公司領導.NET環境下C++語言擴展的設計工作。除本書外，他還撰寫了三本廣受贊譽的圖書：C++Coding Standards、Exceptional C++和More Exceptional C++。
編輯推薦
軟件“風格”所要討論的主題是如何在開銷與功能之間、優雅與可維護性之間、靈活性與過分靈活之間尋找完美的平衡點。在本書中，著名的C++大師Herb Sutter給出了40個編程問題，其目的是爲了使讀者不僅“知其然”，更要“知其所以然”，並幫助讀者在軟件開發中進行正確的決策。
本書是圍繞實際問題及其解決方案展開論述的，對一些至關重要的C++細節和相互關系提出了新的見解，爲當今的關鍵C++編程技術（如泛型編程、STL、異常安全等）提供了新的策略。讀者會在書中找到下列問題的答案。
•可以從STL本身學習哪些庫設計的知識？
•如何避免削弱甚至損害模板代碼的通用性？
•爲什麽不應該對函數模板進行特化？正確的做法是什麽？
•異常安全如何超越TRY和CATCH語句？
•什麽情況下應當“泄漏”一個類的私有成分，怎麽做？
•如何讓一個類不受版本變動的影響？
•使用標准庫容器的實際內存開銷是多少？
•如何使用CONST才能真正優化代碼？
•內聯對程序性能有何影響？
•爲什麽有些看似錯誤的代碼實際上卻能夠通過編譯且運行得很好？爲什麽我們要關心這種情況？
•STD：：STRING的設計有什麽問題？
本書使讀者能夠在設計、架構和編碼的過程中保持良好的風格，從而編寫出更健壯和更高效的C++軟件。
目錄
泛型編程與C++標准庫 1
第1條 vector的使用 2
第2條 字符串格式化的“動物莊園”之一：sprintf 9
第3條 字符串格式化的“動物莊園”之二：標准的（或極度優雅的）替代方案 14
第4條 標准庫成員函數 23
第5條 泛型性的風味之一：基礎 26
第6條 泛型性的風味之二：夠“泛”了嗎 30
第7條 爲什麽不特化函數模板 36
第8條 友元模板 42
第9條 導出限制之一：基礎 51
第10條 導出限制之二：相互影響，可用性問題以及准則 58
異常安全問題及相關技術 67
第11條 Try和Catch 68
第12條 異常安全性：值得嗎？ 72
第13條 對異常規格的實際考慮 75
類的設計、繼承和多態 83
第14條 順序，順序！ 84
第15條 訪問權限的使用 88
第16條 （幾乎）私有 93
第17條 封 裝 101
第18條 虛 擬 110
第19條 對派生類施加規則 118
內存和資源管理 129
第20條 內存中的容器之一：內存管理的層次 130
第21條 內存中的容器之二：它到底有多大？ 133
第22條 進行new操作，也許會抛出異常之一：new的方方面面 140
第23條 進行new操作，也許會抛出異常之二：內存管理中的實際問題 148
優化和效率 155
第24條 常量優化 156
第25條 再論內聯 161
第26條 數據格式和效率之一：什麽時候壓縮是真正重要的 168
第27條 數據格式和效率之二：（甚至更少的）位操縱 172
陷阱、缺陷和謎題 179
第28條 不是關鍵字的關鍵字（或者：另一種注釋） 180
第29條 這是初始化麽？ 186
第30條 要麽double要麽徹底完蛋 191
第31條 狂亂的代碼 194
第32條 小小的拼寫錯誤？鬼畫符似的語言以及其他奇形怪狀的東西 199
第33條 操作符，無處不在的操作符 202
風格案例研究 207
第34條 索 引 表 208
第35條 泛型回調 218
第36條 構造式union 226
第37條 分解std::string之一：概觀std::string 242
第38條 分解std::string之二：重構std::string 247
第39條 分解std::string之三：給std::string瘦身 255
第40條 分解std::string之四：再論std::string 259
參考文獻 267
書摘與插圖
前言
布達佩斯，匈牙利的首都。一個炎熱的夏日傍晚。穿過美麗的多瑙河望去，余晖中的東岸景色優美恬靜。
本書封面上色彩柔和的歐洲風光中，哪棟建築首先映入你的眼簾？幾乎可以肯定，是照片左邊的國會大廈。這棟巨大的新哥特式建築以它優美的圓穹、直插天際的尖塔、不計其數的外牆雕塑以及其他華麗裝飾一下攫住了你的目光，而它更引人注目之處，在于它與四周建築在多瑙河畔那些刻板的實用建築形成了極其鮮明的對照。
爲什麽會有這麽大的差異呢？一方面，國會大廈是在1902年竣工的，而其他味同嚼蠟的建築則大部分都是在二戰以後建成的。
“啊哈，”你可能會想，“這的確解釋了爲什麽差異如此之大。然而這與本書到底有什麽關系呢？”
毫無疑問，風格的表達與你在表達風格時灌注的哲學和思維方式是有很大關系的，這一點不管對于建築學還是對于軟件架構來說都同樣適用。我相信你們都見過像封面上國會大廈那樣宏偉而華麗的軟件，我同樣相信你們也見過僅能工作而且一團亂麻似的軟件。從一個極端的角度來說，我相信你也見過許多過分追求風格反而弄巧成拙的華而不實之作和許多只顧盡快完成任務而毫無風格的“醜小鴨”（而且永遠也不會變成天鵝）。
風格還是實用？
哪個更好？
不要太相信自己知道答案。一方面，除非你給出一個明確的標准，否則“更好”只是一個無意義的評價。對什麽更好呢？在哪些方面更好呢？另一方面，答案幾乎總是這兩者的平衡，最開始總是“這取決于……”。
本書討論的是如何在使用C++進行軟件設計和實現的諸多細節方面找到最佳平衡點，如果更好地理解所擁有的工具和設施，弄清它們應該在什麽時候應用。
快速回答：與四周索然無味的建築相比，封面上的國會大廈是更好的建築嗎？其建築風格更好嗎？如果不加思索就給出答案，很可能你會說“當然”，但是別忘了，你還沒有考慮其建造和修繕的代價呢：
? 建造。在1902年竣工之時，它是當時世界上最大的國會大廈。人們花費了難以想像的時間、不計其數的人力物力來興建它，以至于許多人稱它爲“白象（white elephant）”，意思是耗資過大的美麗事物。考慮這樣一個問題：比較起來，花費同樣的投資能夠建造多少幢周圍那不美觀、單調、或許幹脆是令人厭煩的實用建築？如果你是在一個工程進度壓力遠比這座國會大夏建造時代要大得多的行業工作，你又會怎麽做？
? 修繕。你們中那些熟悉這座建築的人會注意到照片中的建築正在進行修繕翻新，而且這個工作已經持續了好多年，其間又極有爭議地花費了巨量的資金。然而除了最近的這輪昂貴的修繕之外，之前還有多次修繕，因爲遺憾的是，這座建築外牆上的精美雕刻是由錯誤的材料制成的，其材料太過柔軟了。在大樓建成後不久，這些雕刻成了人們持續進行修繕的主要內容，它們逐漸被替換爲更爲堅固而耐久的材料，這些華麗之物的大規模修繕自從20世紀初開始就一直沒停過，持續了近一個世紀。
軟件開發中的情形也與此類似，重要的是在建造的代價和獲得的功能之間、在優雅與可維護性之間、在發展的潛在可能與過分追求華麗之間尋求合理的平衡。
使用C++來進行軟件設計和架構時，我們每天都得面對這些類似的權衡。在本書中討論的問題當中有這樣幾個問題：使代碼成爲異常安全的就意味著將它變得更好了嗎？如果是這樣的，那麽這裏所謂的“更好”是指什麽意義上的呢？什麽時候它可能不是“更好”的呢？在本書中你會得到明確的答案。封裝呢？封裝是否令軟件變得更好？爲什麽？什麽時候封裝反倒不能令你的軟件變得更好？如果你想知道答案，繼續往下讀。內聯是一項有益的優化嗎？內聯是什麽時候進行的呢？（你在回答這個問題的時候可得十分小心了。）C++中的模板導出（export）特性與封面上的國會大廈有什麽共通之處呢？std::string跟多瑙河畔的巨型建築又有何共通之處呢？
最後，在考慮了許多C++技術和特性之後，本書的最後，我們會用一整個部分來考察源自公開發布的代碼中的幾個實際例子，看看代碼的作者在哪些方面做得好，在哪些方面做得不好，以及什麽樣的替代方案可能在實用性與良好的C++風格之間取得更好的平衡。
我希望本書以及Exceptional C++系列的其他圖書能夠開闊你的視野，增加你有關許多細節及其相互關系的知識，讓你進一步了解到如何在編寫自己的軟件時找到合理的平衡點。
請再看一眼封面上的照片，在照片的右上方，你會看到一個熱氣球。如果我們乘坐那樣的熱氣球飛越城市的上空，整個城市的景色將盡收眼底。我們會看到風格跟實用是如何相互影響相互依存的，我們也會知道如何去進行權衡並找到合理的平衡點，所有的決策將各得其所，構成一個富于生機的整體。
是的，我想布達佩斯是一個偉大的城市——充滿著如此豐富的曆史底蘊，充滿著不盡的神秘喻義。
偉大的蘇格拉底
古希臘哲學家蘇格拉底通過問問題來教他的學生們，他精心准備的問題是爲了引導並幫助學生從已知的知識引出結論，並說明他們所學的東西是如何彼此相關、如何與他們現有的知識有著千絲萬縷的聯系的。這種教學方式後來變得如此有名，以至于我們稱它爲“蘇格拉底方法”。而從學生的角度來看，蘇格拉底的這種著名的教學方法能夠吸引我們，讓我們思考，並幫助我們從已知的東西出發去引出新的東西。
本書跟它的前面幾本書（Exceptional C++ [Sutter00]和More Exceptional C++ [Sutter02]）一樣，正是借鑒了蘇格拉底的做法。本書假定你在編寫C++産品代碼已有一些經驗，書中使用了一種問答的形式來告訴你如何有效地利用標准C++及其標准庫，特別地，我們將關注的中心放在如何用現代C++中實施可靠的軟件構造上。書中的許多問題都是從我以及其他人在編寫C++産品代碼時遇到的問題當中提煉出來的。問題的目標是幫助你從已知的以及剛學到的東西出發得出結論，並展示它們之間如何關聯。書中給出的問題會展示如何對C++設計和編程問題作出理性的分析和判斷，其中有些只是常見問題，有些不是那麽常見；有些是非常單純的問題，而有些則深奧一些；另外還有幾個問題之所以放在書中只是因爲……因爲它們比較有趣。
本書涉及了C++的方方面面。我的意思並不是說它觸及了C++的每個細枝末節（那可需要多得多的篇幅了），我只不過是說它是從C++語言和庫特性這塊大調色板上取色，並描繪出一幅圖景，展示那些看似毫無瓜葛的特性如何編織到一起，從而構成常見問題的一個個漂亮解決方案。另外，本書還展示了那些看似無關的部分是如何互相之間盤根錯節、存在著千絲萬縷的聯系的（即便有時你也許並不希望它們之間有什麽聯系），以及如何去處理這些複雜關系。你會看到一些關于模板和名字空間的討論，也會看到一些關于異常與繼承的討論，同樣，另外還有關于堅實的類設計和設計模式的討論，關于泛型編程與宏技巧的討論等等。此外，還有一些實實在在的（而不是一些花邊新聞式的邊欄小字）條款是用來向你展示現代C++中的所有這些部分之間的相互關系的。
Exceptional C++ Style遵循了Exceptional C++和More Exceptional C++前兩本書的傳統：它通過短小精悍的條款的組織形式，並將這些條款再進一步分組爲一個個的主題來介紹新東西。讀過我的第一本書的讀者會發現一些熟悉的主題，不過現在包含了新的東西，諸如異常安全、泛型編程以及優化和內存管理技術。我的幾本書在主題上有部分重疊，但內容上並沒有重複。本書沿襲了對泛型編程和高效使用標准庫的一貫強調態度，包括一些重要的模板和泛型編程技術的討論。
書中的大多數條款最初出現在雜志專欄上以及網上，尤其是我爲C/C++ Users Journal和Dr. Dobb's Journal，已停刊的C++ Report以及其他期刊所寫的專欄文章，另外還有我的Guru of the Week[GotW]問題63到86。不同的是本書中的材料與最初的版本相比經過了重大的修訂、擴展、校正和更新，因此這本書（以及www.gotw.ca網站上的勘誤表）應該被當成原先那些文章的最新而且權威的版本。
預備知識
我假定讀者已經知道一些C++的基礎知識。如果不是這樣，那就先去閱讀一些好的關于C++的介紹和概述的文章或書籍。像Bjarne Stroustrup的《The C++ Programming Language》[Stroustrup00]或者Stan Lippman和Josee Lajoie合著的《C++ Primer（第三版）》[Lippman98] 這樣的經典是良好的選擇。接下來，一定要選擇一本Scott Meyers的經典書籍《(More)Effective C++》[Meyers96,Meyers97]這樣的風格指南，我發現這兩本書基于Web浏覽方式的CD版本[Meyers99]比較方便實用。
如何閱讀本書
本書中的每一條都是以一個謎題或問題來展開的，都有一個介紹性的標題，如下：
##. 條款的主題 難度：#
一段簡短的介紹性文字，說明該條將要討論的內容。
條款主題大致告訴你本條討論的是什麽，通常後面會跟有介紹性的/回顧性的問題[JG問題，JG是指新來的、級別較低的軍官（少尉）]，然後就是主要問題（即Guru問題）。注意，難度系數只是我對特定主題對大多數讀者而言的難度所作的一個大致推測，這就是說你可能會發現一個難度爲7的問題對你來說卻比一個難度爲5的問題要來得簡單。實際上我的前兩本書：Exceptional C++ [Sutter00]和More Exceptional C++ [Sutter02]就曾不斷地收到一些讀者來信說：“嗨！第N條比它實際上要更難（簡單）！”不同的人對于“簡單”的評價標准各有不同。所謂難度系數只是因人而異的，任何條款的難度實際上都是取決于你所掌握的知識和經驗，而其他人則可能覺得它更容易或更難。不過大多數情況下應當將我給出的難度系數作爲一個合理的指示，讓你能夠知道下面會出現什麽問題。
你可能會選擇從頭至尾按順序閱讀本書，這很好，但是不是非要這麽做。你可能決定讀某個特定部分的所有條款，因爲對該部分的主題特別感興趣；這也沒關系。一般來說書中的所有條款都是基本獨立的，除非標注有“之一”、“之二”等的條款之間才會有緊密聯系。因此你在閱讀本書的時候完全可以以跳躍式的方式，順著條款中的交叉引用（包括對我前兩本書的引用）來閱讀。惟一需要注意的地方就是，標注了“之幾”的連續幾個章節之間互有關聯，構成了一個主題，除此之外其他條款你完全可以自由選擇閱讀。
除非我注明某段代碼是一個完整的程序，否則它就不是。記住，代碼示例通常只是從一個完整程序中摘取出來的一小段代碼，不要期望它們都能夠獨立編譯。一般來說你得爲其添上一副骨架才能夠使其成爲一個完整的可編譯的程序。
最後，關于書中的URL：網上的東西總是在變，尤其是那些我無權幹涉的東西。因此隨意將某些網站地址放在一本刊印的書籍中可不大妥當，因爲恐怕在書付印之前有些地址就已經作廢了，更不用說在這本書在你書架上躺了幾年之後了。所以說，當我在書中引用其他人的文章或網址的時候，我給出的地址是鏈接到我自己網站（即www.gotw.ca）上相關內容的地址，後者我是可以控制的，因此我可以在我網站上的相關網頁上隨時作相應更新，讓其中的相關地址指向實際存在的網頁。幾乎所有在書中引用到的其他人的作品我都放在參考書目裏了，而且還在我的網站上也放置了一份副本，其中的鏈接都是有效的。如果你發現本書中的鏈接無效了，請發電子郵件向我告知，我會在網站上更新相關的鏈接（如果我可以找到新地址的話），或者注明鏈接已經失效（如果我無法找到新地址的話）。無論如何，雖說書一旦印刷便白紙黑字，不可再改，但我網站上的相關內容會保持更新。
阿寶價：264 宅配：100
全站熱搜
留言列表
