深度探索c++对象模型

深度探索c++对象模型清晰版，带书签~~~~~~~~~~~~~~~~~~~~~~~~~深度探索C艹+对象模型ins ide The C++ Object ModelYaojiaStanley B i,ippman制作Copyright 1996 by Addison Wesley Longman, Inc.Simplified Chinese Copyright 2001 by Huazhong Science and Technology University Press andPearson Educat ion North asia limitedAll rights Reserved.Publ ished by arrangement with Pearson Educat ion North Asia Limited a pearson Educat ioncoinpany版权所有,翻印必究。本书封面贴有华中科技大学出版社(原华中理工大学出版社)激光防伪标签,无标签者不得销售。图书在版编目(C|P)数据深度探索C+对象模型/〔美) Stanley铞. Lippman著;俟捷详武汉:华中科技大学出版社,2001.5lSBN7-5609-24182/TP·427深l1.①s…②侯lI.血向对象一语言,C+IV. TP312贡任编辑:周筒E.凯出版发行:华中科技大学出版社(武昌喻家山邮编:430074)http://press.hustedu.cn经销:新华书店湖北发行所录排:华中科技大学惠友科技文印中心印刷:潮北省新华印刷丿开本;787×10921/16印张:22.5字数:350000版次:2001年5月第1版印次:2001年6月第2次印刷印数:5001—11000定价:54.00元本立道生(侯捷详序本立道生(侯捷译序对于传统的结构化( sequential)语言,我们向来没有太多的疑惑,虽然在函数调用的背后,也有着堆栈建立、参数排列、返回地址、堆栈清除等等幕后机制但函数调用是那么地自然而明显,好像只是夹带着一个包裹,从程序的某个地点跳到另一个地点去执行。但是对于面向对象( Object Oriented)语言,我们的疑惑就多了。究其因,这种语言的编译器为我们(程序员)做了太多的服务:构造函数、解构函数、虚拟函数、继承、多态……有时候它为我们合成出一些额外的函数(或运算符),有时候它又扩张我们所写的函数内容,放进更多的操作。有时候它还会为我们的objects添油加酷,放进一些奇妙的东西,使你面对 sizeof的结果大惊失色存在我心里头一直有个疑惑:计算机程序最基础的形式,总是脱离不了一行行的循序执行模式,为什么OO(面向对象)语言却能够“自动完成”这么多事情呢?另一个疑惑是,威力强大的 polymorphism(多态),其底层机制究竞如何深度探索￠艹+对象模型( nside the c-+ Object Mode!l)如果不了解编译器对我们所写的C++代码做了什么手脚,这些困惑永远解不开。这本书解决了过去令我百思不解的诸多疑惑。我要向所有已具备C++多年程序设计经验的同好们大力推荐这本书这本书同时也是跃向组件软件〔 component-ware)基本精神的跳板。不管你想学习COM( Component Object Model)或 CORBA( Common Object request BrokerArchitecture),或是SOM( System Object Model),了解C++ Object model,将使你更凊楚软件组件( components)设计上的难点与应用之道.不但我自己在学习COM的道路上有此强烈的感受, Essential com(COM本质论,侯捷译,甚峰99)的作者 Don box也在他的书屮推崇 Lippman的这一本卓越的书籍是的,这当然不会是…本轻松的书籍。某些章节(例如3、4两章)可能给你立即的享受——享受于面对底层机制有所体会与掌控的快乐:某些章节(例如56、7三章)可能带绐你短暂的痛苦——痛苦于艰难深涩、难以吞咽的内容。这些怏乐与痛苦,其实就是我翻译此书时的心情写照。无论如何,我希望透过我的译笔,把这本难得的好书带到更多人面前,引领大家见识C艹+底层构造的技术之美。俟捷2001.03.20于新竹Houd]]h。u.cm本立道生(候捷详序请注意:本书特点,作者 Lippman在其前言中有很详细的描述,我不再多言翻译用词与心得,记录在第0章(译者的话)之中,对您或有导读之功请注意:原文本有大大小小约80~90个笔误。有的无伤大雅,有的对阅读顺畅影响甚巨(如前后文所用符号不一致、内文与图形所用符号不一致—甚至因而导致图片的文字解释不正确)。我已在第Q章(译者的话)列出我找到的所有错误。此外,某些场合我还会在错误出现之处再加注,表示原文内容为何。这么做不是画蛇添足,也不为彰显什么。我知道有些读者会拿着原文书和中译书对照着看,我把原书错误加注出来,可免读者怀疑是否我打错字或是译错了。另一方面也是为了文责自负……唔…万- Lippman是对的而 f. Hou错了呢?!我虽有相当把握,还是希望明白摊开来让读者检验前言(Stanley B Lippman)差不多有10年之久,我在贝尔实验室( Bell laboratories)埋首于C++的实现任务,最初的工作是在 front上面( Bjarne stroustrup的第一个C++编译器),从1986年的1.版到1991年9月的30版,然后移转到 Simplifier(这是我们内部的命名),也就是 Foundation顶目中的C++对象模型部分。在Simplifier设计期间,我开始酝酿这本书Foundation项目是什么?在 Bjarne的领导下,贝尔实验室中的一个小组探索着以C十-完成大规模程序设计时的种种问题的解决之道。 Foundation项目是我们为了构造大系统而努力定义的一个新的开发模型;我们只使用C++,并不提供多重语言的解决方案。这是个令人兴奋的工作,一方面是因为工作本身,一方面是因为工作伙伴: Bjarne, Andy Koenig、 Rob murray、 Martin Carroll、 Judy WardSteve Buroff、 Peter Juhl,以及我自己· Barbara moo管理我们这一群人( Bjarne和Andy除外). Barbara moo常说管理一个软件团队,就像放牧一群骄傲的猫。13深度探索C艹-对象模型( Inside the c+-Ob/ec! Model)我们把 Foundation想象成…个核心,在那上面,其它人可以为使用耆铺设灬层真正的开发环境,把它整修为他们所期望的UNX或 Smalltalk模型。私底下我们把它称为〔rai(传说中耶稣最后的晚餐所用的圣杯),人人都想要,但是从来没人找到过!Grail使用一个由 Rob murray发展出来并命名为ALF的面向对象层次结构,提供一个永久的、以语意为基础的表现法。在 Grail中,传统编译器被分解为数个各自分离的可执行文件, parser负责建立程序的AF表现法.其它每个组件〔比如 type checking、 simplification、 code generation)以及工具(比如browser)都在程序的一个ALF表现体上操作(并可能加以扩展)。 Simplifier是编译器的一部分,处于 type checking利 code generation之间, Simplifier这个名称是由 Bjarne所倡议的,它原本是 cfront的一个阶段( phase在 type checking和 code generation之间, Simplifier做什么事呢?它用来转换内部的程序表现。有二种转换风味是任何对象模型都需要的1.与编译器息息相关的转换( implementation- dependent transformations这是与特定编译器有关的转换。在ALF之下,这意味着我们所谓的tentative” nodes。例如,当 patser看到这个表达式fct)它并不知道是否(a)这是一个函数调用操作,或者(b)这是 overloaded calloperator在 class object fct上的一种应用。默认情况下,这个式子所代表的是一个函数调用,但是当(b)的情况出现时, Simplifier就要重写并调换 call subtree2,语言语意转换〔 Language semantics transformations)这包括 constructor/ destructor的合成和扩展、 memberwise初始化、对于memberwise copy的支持、在程序代码中安插 conversion operators、临时性对象以及对 constructor/ destructor的调用14前言3.程序代码和对象模型的转换( Code and object model transformations这包括对 virtual functions、 virtual base class和 inheritance的一般支持、new和 delete运算符, class objects所组成的数组、 local static class instances、带有非常量表达式( nonconstant expresston)之 global object的静态初始化操作。我对Simplifier所规划的一个目标是:提供一个对象模型体系,在其中,对象的实现是个虚拟接口,支持各种对象模型最后两种类型的转换构成了本书的基础。这意味着本书是为编译器设计者而写的吗?不是,绝对不是!这本书是中一位编译器设计者针对中高级C++程序员所写的。隐藏在这本书背后的假设是、程序员如果了解C++对象模型,就可以写出比较没有错误倾向而且比较有效率的代码。什么是C++对象模型有两个概念可以解释C++对象模型1.语言中直接支持面向对象程序设计的部分2.对于各种支持的底层实现机制语言层面的支持,涵盖于我的C++ Primer一书以及其它许多C++书籍当中,至于第二个概念,则几乎不能够于目前任何读物中发现,只有[ELIS9j和[ STROUP94]勉强有一些蛛丝马迹。本书主要专注于C+对象模型的第二个概念。本书语言遵镅C++委员会于1995冬季会议中通过的 Standard o++草案除了某些细节,这份草案应该能够反映出该语言的最终版本)C++对象模型的第一个概念是一种“不变量”。例如,C++clas的完整 virtuaifunctions在编译时期就固定下来了,程序员没有办法在执行期动态增加或取代其中某一个。这使得虚拟调用操作得以有快速的派送〔 dispatch)结果,付出的成本则是执行期的弹性15深度探索C艹+对象模型( inside the c+· Object Model)对象模型的底层实现机制,在语言层面上是看不出来的—虽然对象模型的语意本身可以使得某些实现品(编译器)比其它实现品更接近白然。例如, virtualfunction calls,一般而言是通过一个表格(内含 virtual functions地址)的索引而决议得知。一定要使用如此的 virtua! tablc吗?不,编译器可以自由引进其它任何变通做法。如果使用 virtual table,那么其布局、存取方法、产生时机以及数百个细节也都必须决定下来,丽所有决定也都由每一个实现品(编译器)自行取舍不过,既然说到这里,我也必须明确告诉你,目前所有编译器对于 virtual function的实现法都是使用各个 class专属的 virtual table,大小固定,并且在程序执行前就构造好了如果C+对象模型的底层机制并未标准化,那么你可能会问:何必探讨它呢?主要的理由是,我的经验告诉我、如果一个程序员了解底层实现模型,他就能够写出效率较高的代码,闫信心也比较高。一个人不应该用猜的方式,或是等待某大师的宣判,才确定“何时提供一个 copy constructor而何时不需要”。这类同题的解答应该来自于我们自身对于对象模型的了解写这本书的第二个理由是为了消除我们对于C++语言(及其对面向对象的支持)的各种错误认识。下面一段话节录自我收到的一封信,来信者希望将C++引进其程序环境中我和一群人一起工作,他们过去不曾写过(或完全不熟悉)C++和OO。其中一位工程师从1985年就开始写C了,他强烈地认为C++只对那些 user-type程序才好用,对 server程序却不理想,他说如果要写一个快速而有效率的数据库引擎,应该使用C而非C++。他认为C++庞大又迟缓C++当然并不是天生地庞大又迟缓,但我发现这似乎成为C程序员的个共识。然而,光是这么说并不足以使人信服,何况我又被认为是C+的“代言人”。这本书就是企图极尽可能地将各式各样的 Object facilities(如 inheritance、virtual functions、指向 class members的指针…)所带来的额外负荷说个清楚16