本立道生:倏捷译序 请注意:本书特点,作者 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的指针……)所带来的额外负有说个清楚