华口科技大字出版 Pearson education(培生教育山版美团) 深度探索 C++对象模型 Inside The C++ Object Model Stanley B. Lippman著 侯捷译 Object Lessons The Semantics of Constructors The semantics of data The Semantics of Function Semantics of Construction, Destruction, and Copy Runtime Semantics On the Cusp of the Object Model
笨度琛索C+对象模型 sidc The Ci+ object. Modn] anlcy B lipon Copyrigt 1996 ty Addison Wesley Logman, 1 simplified Cr inese Coyright 2001 by Iluazh ng Science and Technology Un vcl,sitv P: ess and Pearson educat ion north asia ;ini.ed All rig: ts Reserved PL: bl: shed by arrangent: t with Pearson Educetion Nort Asia Limited. a Pearson: Eucation 版权所有,翻印必究 本书缸面贴有华中科技大学出版社(原华中理工大学出版社)激光防伪标签,无标签 者不得销售。 图书在版编目(G|P)数据 深度索C对象模型;(关) Stanley 8. Lippman著:佚挞译 一武汉:华中科技大学出版社,2001.5 l≤BN7-56092118-2:TP·427 II.血对象一语言,C+ lV.∴F3【2 贞任编辑:周筠E凯 版发行:华技人学版社(武吕喻篆山邮编:43074 h:tp: / /prEss. hust. edu. cn 经销:新华再店湖北发行所 录排:华中科技人学惠友科技文印中心 印刷:北省新华印刷厂 开本:787×1092116 印张:2.5字数:350000 版次:201年5月第1版 印次:201年6月第2次印刷 印数:5001-11000 定价:54.00元
深度探索 C十+对象模型 Inside The C++ Object Model Stanley b. Lippman著 侯捷译 华中科技大学出版社 Pearson Education(培生教育出版集团)
木立遒生(侯捷译序 本立道生 (侯捷译序 对于传统的结构化( sequent ip)言,我们向买没有太多的疑惑,虽然在函 数调用的背后,也有着堆栲建立、参数排列、返闻地址、堆栈清除等等幕后机制 但函数调用是那么地自然而明显。好像只是夹带着个包裹,从程序的￥一个地 点跳到另个地点去执行 但是对于面向对象( Object Oriented)语言,我门的疑感就多,,究因,这 种语宮的编译器为我们(程序员做了太多的服务;构造函数、解构函数、虚拟 函数、继承、多态…有时候它为我们冷成出一些额外的函数(或运算符),有 时候它又扩张我们所写的函数内容,放进史多的操作。有时候它还会为我们的 objects添油加酯,放进一些奇妙的东西,使你面对 sizeof的结與大惊失色 存在我心里头一自个疑感:计算札程序最基础的形式,总是脱离不了…行 行的循序执行模式,为什么U(面向对象)语言却能够“户动完成”这么多事情 呢?另一个疑惑是,威力强大的 polymorphism(多态),其底层机制究竟如何
深度探裳C++对象型( insic th?·- Object Mod 如謀不了解编译器对我们所写的C+代码做了什么手脚,这些困惑永解 不开。 这本书解决了过去令我百思不解的诸多疑惑,我要向所有已具备C艹+多年 程序设汁经殓的同们大力推荐这本书 这本书同时也是跃向组件软牛(com。 onent-ware)基本精冲的跳板.不管你想 学与COM( Componcnt Object Model我 CORBA( Common Object Request Broker Architecture},或是SOM( System Object Moce!),了解C-+ Object Model:将 使你更清楚软件组件( components)设计上的难点与应用之道.不但我自己在学 习COM的路上有此强烈的感受, Essential COM(CoM本质论,侯捷译,柞 峰1998)的作者 Don Box tt.在低的书中推崇 Lippman的这本卓越的书籍 是的,这当然不会是…本轻松的书籍,某些章节(例如3,4两章)可能给你 立的亨受——亨受于而对底层机制有所休会与掌控的快乐;某些章节(例如5 6,7三章)可能带给你短暂的痛苦—一痛于艰难深涩、难以吞咽的闪容。这些 快乐与痛芒,其实就是我翻谬此书时的心青写照。无论如何,我希望透过我的译笔 把这木难得的好书带到更多入面前,引领大家见识C++底层构造的技术之美 侯捷2001.0320于新竹 jhcu3jh:cu.二on
本立道生:倏捷译序 请注意:本书特点,作者 Lippman右其前言中有很详细的苗还:我不再多言 翻译用词与心得,记录在第0章(译者的活)之中,对您或有导读之功, 请注意:原文本有大大小小约8090个笔误,有的无伤大雅、有的对阅读顺 杨影响甚巨(如前后文所用符号不一致.内文与图形所用符号不一致——甚至因 而导致图片的文字解烽不正确〕。我已在第0章〔译者的话)列出我找到的所有 错误。此外,某些场合我还会在错误出现之处再加注,表示原文内容为何,这么 做不是画蛇添足,也不为彰显什么.我知道有些读者会拿着原文书和中泽书对照 着看,我把原书错误加注出来,可免读者怀疑是否我打错字或是译错了,另一方 面也是为了文责自负…语……万一 Lippman是对的而JHou错了呢?我 虽有相当把握,还是希望明白摊开来让读者检验
前言 前言 (Stanlcy B Lippman) 差不多有10年之久,我在贝尔实验室( Bell laboratories)埋首于C艹的实 现任务,最初的工作是在crnt上面( Bjarne Stroustrup的第…个C++编译 器),从1986年的11版到1年9月的3.0版,然后移转到 Simplifier这是 我们内部的命名冫,也就是 Foundation项目中的C艹+对象模型部分.在 Simplifier没计期间,我开始酝酿这本书 Foundation项目是什么?在Bjne的领导下,贝尔实验室中的一个小组探 索着以C++完成大规模程序设计封的种种问题的解决之道. Foundation项目是 我们为了构造大系统而努力定义的一个新的开发模型:我们兵使用C+,并不提 供多重语肓的鲆决方案,这是个令人兴在的工作,一方面是因为工作本身,一方 面是因为作伙伴: Barne, Andy Koenig, Rob murray, Martin Carrol、 Judy ward Steve Buro、 Peter Juhl,以及我自己. Barbara MoD管理我们这群人( Bjarne和 And除外)· Barbara Moo常说管理一个软件团队:就像放牧一群骄傲的猫
深度探素C+-对象模型( inside ine c++ Object Mode!) 我们把 Foundation想象成一个核心,在上面,其它人可以为使用者铺谡 层真工的发环境,把它整修为们所期望的UNX或 SMalltalk模型,私底下 我们把它称为Gral传说中耶稣最后晚镫所用的至杯),人人都想要,但是人 来没人找圳过! Gail使一个日 Rob Murray发展出来并命名为ALF的面向对象层次结 构,提供一个永久的、以语意为基础的表现法。在Grai中,传统编译器被分解 为数个各自分离的可执行文件, parser为责建立程序的ALF表现法.其它每 个组件(比如 type checking, simpl∫ cation, code generation)以及二具(比如 browser)都在程序的个ALF表现体二探作(并可能加以扩展). Simplifier是 编译器的一部分,处于 type checking和 ccde generation之间. S: mplifier这个名 称是由Bane所倡议的,玄原本是 effort的一个阶段( phase 在 type checking和 code generation之间, Simplifier做计么事呢?它用来转 换内部的程序表现。有二种转换风味足任何对象模型都需要的 1.与编译器息息相关的转换! Implemenlation-dependent transformations) 这是与特定编译器有关的转换。在AF之下,这意味着我们所谓的 tentative" nodes,例如,当 parser看到这个表达式 fct i 它并不知道是香(a)这是…个函数调用操作,或者(b)这是 overloaded ca I tr在 class object fct上的一种应用.默认情况下,这个式子所代表的是一个 函数调用,但是当(b)的青况出现讨, Simplifier要重写并调换 call subtree 2.语言语意转换 Language semantics transformations 这包括 constructor/destructor的合成和扩展、 memberwise初始化、对于 memberwise copy的支持、在程序代码中安插 conversion operators、临时性对象, 以及对 constructordestructor调用
前言 3.程序代码和对象模型的转换( Code and objet mocel transformaTions) 这包括对 virtual functions, virtual base class和 inheritance的般支捋、nw 和dete运算符、 class ob'ects所组成的数组、 local static class instances、带有非 常量表达式( nonconstant eXpress: on)之 global object的静态初始化操作,我对 Simplifier所规划的-个目是:提供一^对象嫫型体系,在其斗,对象的实现是 个虚拟接口,支持各种对象模型 最后构种类型的转换构戌∫本书的基础、这意味着本书是为编译器设计者而 写的吗?小是绝对不是!这本书走由一位编译器设计者针对中高级C+-程序 员所写的,隐城这本书背后的假改是,程序员如果∫解C++对象嫫型,就可 以写出比较没有错误候问重且比较有效率的代码 什么是C++对象模型 有两个概念可以解释C++对象模型 语言屮直接攴持面向对象程序设计的部分 2.对于冬种支持的底层实现机制 语言层的支持,渊盖于我的C++Pnmr一书以及其它许多C++书当 中,至于第二个喂念,则几乎不能够于目前任甸读物中发现,只有[ ELLIS(]和 STROUPO4勉强有一些蛛丝马透.本书主要专注于C+4对象模型的第二个概 念。本书语宮遵循C艹委员会于1995冬季会议牛通过的 Standard C++草案 除了某些细节,这分草案应该能够反映出该语言的最终版本) C+对象模型的第一个念是一种“不变量”,例如,C++cas的完整 virtual functions在编译时期就圖定下来了,程序没有办法在执行期动态增加或取代其 中某一个这使得虚拟谓用操作得以有快速的派送( dispatch)细果,付出的成本 则是执行期的強性
深度探索C+-对象模型( inside the c++ Object Model) 对象模型的底层实现机制,在语音层面上是看不出来的—虽然对象模型的 语意本身可以使得些实现品(缃译器:比其它实现品更接近白然。例虹,ⅵ rusal unct o: 1 calls,-般而言是通过一个表榨(内含 virtua functions地址)的素引 决议得知,一定要使用如此的 virtual table吗?不,编译器可以自白引进其它任 何变通做法。如果使用 v rua] table,那么其布局、在取方法、产生时机以及数百 个细节也都必须决定下来,所有决定也都由每一个实现品(编译器)自行取舍 不过,既然说到这里,我也必须明确告诉你,日前所有编译器对于 virtual function 的实现法都是使用谷个 class专属的wi; ual able:人小固定,并且在程序火行前 就构造好了。 如果C++对象模型的底层材制并未标准化,那么你可能会问:何必探讨它 呢?主要的理由是,我的经验告诉我,如果一个程序员了解底层实现模型,他就 能够写出效率较高的代码,自信心也匕绞高,一个人不应该用猜的方式,或是等 待某大师的宣判,才确定“何时提供一个 coPy cOstructor而何时不需要”,这类 问题的解答应该来自于我们自身对于对象模型的了解 雩这本书的第二个理由是为了消除我们对于C++语言(及其对面向对象的 支捋的各种错误认识、下面段话录自我收到的封信,来信者希望将C++ 引进其程序环境中 戎和一群人一起工作,他们过去不曾写过(或完全不熟悉)C++和O0O.其 中一位工程帅从1985年就升始写C了,他强烈地认为C++兵对那些 user-tyre 序才好用,对 server程序却不理想,他说如果要写一个快速而有效率的数据库 引擎,应该使用C而非C艹.他认为C++庞大又迟缓 C+当然并不是天生地庞大又迟缓,但我发现这似乎成为C程序员的 共识.然而,光是这么说并不足以使人信服,何况我又被认为是C+的“代言 人”·这杰书就是企图极尽可熊地将各式各样的 ODject facilities(如 inheritance virtual functions、指向 class menbers的指针……)所带来的额外负有说个清楚
