┌───────────────────┐
│全世界上百萬名 C++ 程式員之中, │
│超過四分之三的人皆受惠於本書歷代版本!│
└───────────────────┘
由 C++ 發明人 Bjarne Stroustrup 所著的這本書,是 C++ 領域地
位最尊、讀者最多的書。這一版又添加兩個附錄:國際化議題、標準
程式庫的異常處理技術。全書以 ANSI/ISO C++ 規格為準,全盤涵蓋
C++ 語言本體、標準程式庫、程式設計關鍵技術,並將各主題做最完
美的整合,堪稱權威之作。
本書詳盡闡述 C++ 語言特徵及標準程式庫元件,譬如:
* 抽象類別:介面
* 類別階層:物件導向編程
* 模板:具型別安全性質的泛用軟體
* 異常處理機制:一致性的錯誤處理
* 命名空間:大型軟體的模組化處理
* 執行期型別識別:低耦合性軟體系統
* C++ 之中的 C 子集:回溯相容性、低階任務
* 標準容器與演算法
* 標準字串、I/O 資料流、數值運算
* 與 C 的相容性、國際化議題、完善的異常處理策略
Stroustrup 不僅讓新手更容易親近 C++, 新增的技術資訊更讓老手
見宗廟之美百官之富;此中譯本提供比原著更圓潤的敘述,讓您更能
無礙吸收本書的菁華。
─────────────────────────────────────
● 增訂版譯者序
上士聞道,勤而行之;
中士聞道,若存若亡;
下士聞道,大笑之。
-- 《老子》
在小眾的繁體中文市場,一本非速成、非大眾取向的專業電腦書,能
有再刷 (printing) 的機會,就很值得喜悅了;若能夠再版 (edition)
,甚至增訂版,那就更令人振奮。很榮幸的,本書《C++ 程式語言經
典本》兩者皆有;不過,這當然是受到原著的庇蔭。
本書的英文原著 The C++ Programming Language,暢銷三版之後,
於西元 2000 年推出了 The C++ Programming Language, Special
Edition 這個特別版本,除了封面變成硬殼精裝、更多修訂內容之外
,主要是多了兩個新附錄:附錄D、國際化議題,附錄E、標準程式
庫的異常處理安全性,共約 100 頁。
近年來 C++ 的主要對手是 Java(至於微軟新推出的 C# 嘛……呃…
…有待時間證明)。浸淫 Java 愈久,愈對它程式庫嚴密的異常處理
羅網感到放心,愈對它周到的國際化支援感到窩心。另一方面,開放
原始碼陣營(像 Linux、FreeBSD、GNU)對國際化機制也已如火如荼
展開標準化、統整化動作,Unicode、XIM 等標準也攻城掠地頗有斬
獲。對這些議題,C++ 有任何回應嗎?C++ 是否落伍了呢?非也!
1998 年定案的 C++ 標準對這些議題都早有佈局,但缺少良好的統整
性教學材料。現在這本書多了這些令人鵠望已久的內容,C++ 幾無祕
密可言,可讓人放心倚靠。
這兩個附錄真是及時雨啊!
現在這本《C++ 程式語言 經典增訂版》除了如實反映 Special Edition
的修訂、增訂內容之外,尚有幾項新特色:
1. 版面:改用《物件導向設計模式》【註1】的版面,希望能有
煥然一新的視覺效果。
2. 中英版本頁碼對照:最近人文領域的中譯書籍,尤其是比較嚴
謹的著作,漸漸流行「中英版本頁碼對照」作風【註2】,以
方便因為某些原因,需要將中英版本相互對照的讀者。此外,
正如我在《物件導向設計模式》所說,這麼一來就不必再專門
為中文版重新改寫書末索引的頁碼數字。因此,我沿用往例,
在譯本的左右留白處,用 293 這樣的方框標明該段落是由原
著第幾頁翻譯過來的。
3. 譯詞:我參考國內知名作家侯捷先生的譯詞,盡量取得共識。
書末索引也會列出原文、新譯詞、舊譯詞的對照表。
4. 潤飾:我又將全書譯文潤了幾次。不過,這仍然是相當嚴謹的
書(內容嚴謹,字句也嚴謹),仍然需要以嚴謹的心態來研讀
。給您一點鼓勵:既然您慧眼選中了本書,表示您有求真求實
的勇氣;功不唐捐,你會有更深的洞見、更多的收穫。
5. 答客問:我發現本書作者 Bjarne Stroustrup 的網站裡有一
篇不錯的 FAQ 文章【註3】,釐清不少 C++ 的知見,大師風
範,躍然紙上,十分精彩。特別徵得他的同意,摘錄大部份內
容加入此譯本,以饗讀者。
就在 911 準戰爭事件重創美國、納莉颱風肆虐北台灣的同時,我正
在為本書做最後校閱。望著稿子,兩年前的悸動猶存;尤其是檢閱到
第廿三章〈系統開發與設計〉時,更是久久不能自已……或許我們都
該學著不再重蹈歷史覆轍,對歷史經驗謙卑。
越讀越佩服 Bjarne Stroustrup 以長年沙場經驗昇華的洞見。
不管您是老讀者還是新讀者,希望這本新的增訂版,都對你有所幫助。
葉秉哲 于台北 2001/09/17
pj...@cis.nctu.edu.tw
http://william.cswiz.org/CPPbook/
末了再做一點小補充。此中譯本依據的是原著 Special Edition 的第 4 勘誤
(詳見原著網站:http://www.research.att.com/~bs/3rd_errata.html),
至於譯本本身的勘誤(如果有的話,呵),請到 http://william.cswiz.org/CPPbook
來查看。
* 註1:即 Gamma 等人("GoF")之 Design Patterns 的中文版,
葉秉哲譯,培生,台北,2001/04。
* 註2:像彭淮棟譯《西洋政治思想史》、許家馨與李冠宜譯《法律
的概念》、廖世德譯《全然的自由:克里希那穆提要義》、于曉等
譯《新教倫理與資本主義精神》等書。
* 註3:http://www.research.att.com/~bs/bs_faq.html。
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
≡ 何陋居 ≡ 我們對古典的書太冷漠、對流行的書太熱中,
對價格太在意、對價值太低估。 高希均
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
--
* Origin: ★ 交通大學資訊科學系 BBS ★ <bbs.cis.nctu.edu.tw: 140.113.23.3>
這點是我一直覺得很奇怪的事
如果中英版的頁碼都列出,倒還可以接受
但是只列出原文書的頁碼卻不列中文書的頁碼
不知道是什麼意思 (還可以稱為一種風格哩,不懂)
【例如】
多形:請參考第 198 頁 (第 198 頁,嗯,我找到了,很好)
【但是】
多形:請參考第 154 頁,但是請注意,是原文書的第 154 頁喔
(啥?那中文版的是在第幾頁呢?這比較重要吧)
> 正如我在《物件導向設計模式》所說,這麼一來就不必再專門
> 為中文版重新改寫書末索引的頁碼數字。
那麼需要中文版頁碼索引的讀者怎麼辦?
不知有沒有人和我有同感?各位有何看法呢
好問題。
這麼做, 主要是避免一本書出現太多不同的頁碼系統, 容易造成混淆。
同步維護兩套頁碼系統, 對電腦麻煩(對 LaTeX 或許簡單),
對讀者也麻煩。
所以我傾向於:讓「中文書頁碼」只在「目錄」的地方有作用,
其他所有內文的交互參考及索引, 則全以「原文書頁碼」系統為準。
> > 正如我在《物件導向設計模式》所說,這麼一來就不必再專門
> > 為中文版重新改寫書末索引的頁碼數字。
> 那麼需要中文版頁碼索引的讀者怎麼辦?
> 不知有沒有人和我有同感?各位有何看法呢
索引的目的, 主要是為了檢索資訊;
只要能簡單的檢索到, 又何必在意是哪一種系統?
如果列原文書頁碼,除非讀者手上有原文書
否則這個頁碼對讀者來說是沒什麼意義的
相反的,列出「本書」的頁碼,讀者才翻得到檢索得到
大部分情況下讀者不會有了翻譯書又買原文書吧
所以我才會不懂,檢索、交互參考為何要用原文書的頁碼
(讓人懷疑譯者是不是懶得建索引 ; p )
如果以下前提皆成立, 的確可以讓譯者在產生「中文版索引」時省下不少工夫:
1. 原著出版社願意提供原著的原始檔
2. 譯者或排版人員熟悉原著所使用的排版軟體
否則, 如果面對像 The C++ Programming Language, Special Edition
這種恐怖的書(索引居然就佔了 52 頁), 我很懷疑到底有沒有人
願意手動去製作對等的中文版(我兩年前為這本書幹過兩次,
實在是痛苦萬分的回憶... 有興趣的可翻翻舊信...)。
不懂耶,中文版索引、交互參照不都是根據譯者自己的原始檔嗎
【索引例】
多形:「本書」第45頁、第58頁、第163頁、第751頁
【交互參照例】
...這就是多重繼承可能發生的問題 (請參考「本書」第89頁)
這些「本書第幾頁」的頁碼是來自譯者自己的檔案,由自己的排版軟體產生
製作「中文版索引、交互參照」為什麼會要用到原著的原始檔和排版軟體呢
假設我是英文書作者, 你是中文版譯者。
假設我的英文書有 50 頁英文索引。
如果我不把英文版原始檔拿給你, 你要如何把我這 50 頁的英文版索引
裡面的英文版頁碼換成中文版的頁碼?
請先試著想一想你要進行的每一個步驟。
想通了之後, 再回頭看看我所列的第二則前提。
假設我是英文書作者, 你是中文版譯者。
假設我的英文書有 50 頁英文索引。
如果我不把英文版原始檔拿給你, 你要如何把我這 50 頁的英文版索引
裡面的 50 * 100 = 5000 筆索引項所伴隨的 5000 筆英文版頁碼
換成對應的中文版的頁碼?
假設建立一筆索引以 2 分鐘來算的話(查英文索引,再建譯本索引),
5000 * 2 = 10000 分 = 167 小時,
一天工作 8 小時,大約需要 21 個工作天,的確要花相當多的時間。
--
[1;33mo [31mR [35mi [36mg [37mi [34mN [31m: [36m成 [37m大 [32m資 [33m工 [36mB [31mB [37mS [35m站 [37m(140.116.247.7) [m
[1;31m@ [m [37mbbs.csie.ncku.edu.tw [1;35mFrOm [37m: [m27-1-43.dynamic.lcs.mit.edu
不過還是不太懂為什麼要附上原文板的參照頁數
雖說有些人會中英文版都買
可是還有更多的人只買一種啊...
附上原文本的參照頁數 丈樣不是反而會對讀者產生困擾嗎???
--
[1;32m※ Origin: [33m交大資工鳳凰城資訊站 [37m<bbs.csie.nctu.edu.tw> [m
[1;31m◆ From: [36m61-223-3-193.HINET-IP.hinet.net [m
其實若不是為了顧及部份根深柢固的習慣,
我原本在製作 Design Patterns 這本大量仰賴原著頁碼的書時,
甚至想要連 *中文頁碼* 也撤掉, 完全以 *原著對應頁碼* 角度思考,
直接編頁成 1, 2, 3, 4(a), 4(b), 5(a), 5(b), 6, 7, 8 ...
或 1, 2, 3, 4-a, 4-b, 5-a, 5-b, 6, 7, 8 ...
或 1, 2, 3, 4a, 4b, 5a, 5b, 6, 7, 8 ...
這樣子, 整本書就完完全全只有一套編頁系統。
(不過, 出版社在處理開數落版時, 會比較麻煩, 呵)
不過, 《物件導向設計模式》這本書已經革了夠多的命了,
我不想在這地方再多革一個命... :q
此外, 對學生而言, 知道原著頁碼還有個好處:
當用原文書的老師叫大家翻到 xx 頁的時候,
你不會因為自己用的是中譯本就翻錯頁... 呵。
還是不明白,一定是我什麼地方搞錯了,請幫我指正,下面是我的「步驟」
> > 【索引例】
> > 多形:「本書」第45頁、第58頁、第163頁、第751頁
當我翻譯的過程中看到一個「多形」,我就插入一個 bookmark 在上面
假設這個點將來文書處理器編排後會是第45頁(不管原文書是第幾頁)
繼續往下翻譯。
又陸續翻譯到幾個有關「多形」的內容,各放了一個 bookmark
假設編排後分別會是在第58頁、第163頁、第751頁
全部翻譯完畢以後,建索引時,文書編輯器自動會根據插入的 bookmarks
幫我產生這樣的索引:
多形:45、58、163、751
以這樣的思考邏輯,實在搞不懂為什麼會要用到原文書的原始檔案
謝謝
這樣一來, 就等於是你自己在 *從零開始製作* 索引,
而不是 *站在原文書的基礎上來轉換/轉譯* 索引。
我想我大概明白了,可不可以這麼說:
國內譯者基於某些原因,例如原著過於龐大或截稿的時間緊迫
而沒有去插對應的 bookmarks,或是根本很難一一找到對應的點
以致他們要建索引、交互參照時,發明一種「革命」的方法解決:
列出原文書的頁碼而不是「本書的頁碼」
(這樣可以直接用原著的索引,只要把名詞如 polymorphism 翻譯為多形,
頁碼就留著不必更動它。所以才會說有原始檔的話就會更方便)
至於讀者覺得奇怪,這樣有什麼好處的問題,可以這樣解釋:
有了原著的頁碼,要回去參考原出處可以很快找到
還有,在使用原文書的課堂上,可以很方便地和教授同學們同步
(當然其實這樣已經略為失去交互參照的本意,變成另一種功能了)
這樣解釋對不對?
別人的心態如何, 我不便揣測;
但單以我個人的心態而言, 的確如你所說的。
此書兩年前的版本, 我的確是把索引頁碼弄成中文版的, 還搞了兩次。
但兩年後的今天, 我卻對兩年前的處理方式很不滿意。
至於「所以才會說有原始檔的話就會更方便」,
是指:如此一來, 便可在最省力的情況下替索引弄出中文版的頁碼。
> 至於讀者覺得奇怪,這樣有什麼好處的問題,可以這樣解釋:
> 有了原著的頁碼,要回去參考原出處可以很快找到
> 還有,在使用原文書的課堂上,可以很方便地和教授同學們同步
> (當然其實這樣已經略為失去交互參照的本意,變成另一種功能了)
> 這樣解釋對不對?
對普通書籍來說, 這倒不是很關鍵性、很值得大書特書的作用啦。
但對一本像是 Design Patterns、Refactoring 之類
與原著頁碼系統緊密結合的書來說, 另起一個中文頁碼系統,
反而容易阻礙持有中譯版的人與持有英文版的人之間的交流溝通。
此外, 留有原著頁碼資訊, 也有利於讀者自行勘誤
(如果中譯版的譯者沒有提供追蹤服務的話...),
也更易讓讀者檢驗譯者的譯事是否嚴謹
(所以像聖經的各國語言譯本, 都會保留同一套章節編號體系)。
剛好前陣子買了Design Patterns的中譯本, 以內容來說
的確翻得不錯, 不過其中 "原文頁碼" 的問題也造成了滿
大的困擾, 由於是第一次讀這本書, 每當一參考到其他Pattern
時, 就得找半天, 最後反而降低了我隨書中內容參考相關
內容的意願, 這個不方便即使在看過一遍後, 在重讀時一
樣存在, 葉兄提的這兩點感覺上在一般國內讀者身上似乎
很難存在吧, 有多少人買了譯本, 還想要跟原文做比對校
對呢? 我想大家買譯本就是單純的用中文看這本書的內容
罷囉. 至於讀中譯版的人想跟原文的人做溝通, 那不如在
保留原文頁碼之餘, 同時也加上中譯版的頁碼就更完美囉...:)
> 別人的心態如何, 我不便揣測;
> 但單以我個人的心態而言, 的確如你所說的。
同一章節的編號體系只能說是一樣的目錄而已。
不能算是一樣的索引。
如果要考慮這麼多的問題,那不妨頁對頁的翻譯就行了。
至於每頁內容不均的狀況,在這種要求下也就不必太在意。
以我的製作法, 已經不可能「頁對頁的翻譯」了.
頁碼 shift 的情況, 越往後面越嚴重。
硬是要遷就「頁對頁的翻譯」上綱, 你就會收到一本字體過小、行距過密的書。
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
≡ 何陋居 ≡ 我們對古典的書太冷漠、對流行的書太熱中,
對價格太在意、對價值太低估。 高希均
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
哇!果然又有令人一開眼界的技術
這樣的話,完全可以解決索引、交互參考的問題
要避免頁碼 shift 可以適時地插入一些插圖或「譯者的話」等來補白
怕字體過小行距過密可以用 2:1 (兩頁中文=一頁原文) 的頁對頁方式
這樣的 idea 真不錯耶,實作上可行嗎?應該還好吧?
侯捷的近兩年譯作(像 C++ Primer、Effective C++、More Effective C++、
Essential C++ 系列)都是用這種方式。
不過你也可發現, 自從他創出這種方式之後,
版面的天地留白變少了, 行距變小了,
過去令人稱道的「譯者的話」也銳減。
許多都是為了遷就這「頁對頁的翻譯」的製作上綱。
所以遇到像 Exceptional C++ 這種書, 他也被迫採取類似我的做法。
> 這樣的話,完全可以解決索引、交互參考的問題
> 要避免頁碼 shift 可以適時地插入一些插圖或「譯者的話」等來補白
所謂的「頁碼 shift」, 通常不是「原著頁碼 = 譯本頁碼 + n」,
而是「譯本頁碼 = 原著頁碼 + n」,
除非我們用文言文來翻譯... :q
所以你所謂的「插圖」、「譯者的話」等方式,
只會更擴大「頁碼 shift」問題。
> 怕字體過小行距過密可以用 2:1 (兩頁中文=一頁原文) 的頁對頁方式
> 這樣的 idea 真不錯耶,實作上可行嗎?應該還好吧?
這樣可能反而會增加偶數頁的留白,
而且整本書頁數加倍, 現實上會有問題。
侯捷的近兩年譯作(像 C++ Primer、Effective C++、More Effective C++、
Essential C++ 系列)都是用這種方式。
不過你也可發現, 自從他創出這種方式之後,
版面的天地留白變少了, 行距變小了,
過去令人稱道的「譯者的話」也銳減。
許多都是為了遷就這「頁對頁的翻譯」的製作上綱。
所以遇到像 Exceptional C++ 這種書, 他也被迫採取類似我的做法。
> 這樣的話,完全可以解決索引、交互參考的問題
> 要避免頁碼 shift 可以適時地插入一些插圖或「譯者的話」等來補白
所謂的「頁碼 shift」, 通常不是「原著頁碼 = 譯本頁碼 + n」,
而是「譯本頁碼 = 原著頁碼 + n」,
除非我們用文言文來翻譯... :q
就以 The C++ Programming Language, Special Edition 這本書為例,
若不計書前序言、書末索引、我替中譯本新增的第零章〈答客問〉,
原著共 968 頁, 譯本則有 1238 頁, 足足多出了 270 頁。
--
[1;33;44m [m
[1;33;44m [1;33;41m全像光學實驗室 Master Chang [1;33;44m [m
[1;33;44m [1;33;41m研究員兼工友兼老闆小跟班/_\ [1;33;44m [m
[1;33;44m [m
--
[1;32m※ Origin: [33m碩誠 Linux 資訊站 [37m<bbs.sayya.org> [m
[1;31m◆ From: [36ma004.sci.ccit.edu.tw [m
舉個例,當您想參考 Adaptor(139) 時,照最前面「導讀」的方法
順著標示在左右留白處的「方框框頁碼」去翻 (而不是照本書頁碼)
翻到「方框框139頁」就可以找到 Adaptor,而其實它是本書第159頁
以上過程,我相信搜尋「方框框頁碼」和搜尋「本書頁碼」的速度
應該是一樣的。如果您同意這點,那就不是「原文頁碼」造成的困擾
> 侯捷的近兩年譯作(像 C++ Primer、Effective C++、More Effective C++、
> Essential C++ 系列)都是用這種方式。
> 不過你也可發現, 自從他創出這種方式之後,
> 版面的天地留白變少了, 行距變小了,
> 過去令人稱道的「譯者的話」也銳減。
> 許多都是為了遷就這「頁對頁的翻譯」的製作上綱。
造成這種原因的因素很多,根據我的觀察大部分的原因是中譯本的幅面較窄。
且翻譯出來的文句過於拘泥原文的句式,因而太長不夠簡潔,
在正常的情況下,一段意譯的中文是要比英文短的。
此外字體的選擇也是重要的因素,使用明體字是最普遍,
但明體字的字體佔面積最大,變小之後最不清楚,且最為擁擠的字體。
通常,換成楷書或仿宋在小字的情況下都會好很多。
或許我該來試著譯一本,來解釋我的做法。:-)
除非真的大幅意譯, 省去許多原著匠心獨運的轉折、層遞及隱喻,
否則白話中譯文很難比英文短吧。
當然, 反之亦然。
每一種語言都有各自的經濟特性, 很難用另一種語言同樣經濟地表現出。
> 此外字體的選擇也是重要的因素,使用明體字是最普遍,
> 但明體字的字體佔面積最大,變小之後最不清楚,且最為擁擠的字體。
> 通常,換成楷書或仿宋在小字的情況下都會好很多。
咦, 楷書在小字的情況下會好很多? 會嗎?
美不美先不論, 明體才是在同樣面積底下最經濟、筆畫最清晰的吧?
否則「小字之最」的報紙豈不應該改用楷書?
至於仿宋嘛... 或許也很經濟、筆畫也很清晰,
但比較正經、不帶色彩的文章, 似乎不適合用之。
> 或許我該來試著譯一本,來解釋我的做法。:-)
呵呵。 :)