《深度探索C++对象模型》

编辑推荐

　　如果你是一位C++程序员，渴望对于底层知识获得一个完整的了解，那么《深度探索C++对象模型》正适合你。

内容简介

　　作者Lippman参与设计了全世界套C++编译程序cfront，这《深度探索C++对象模型》就是一位伟大的C++编译程序设计者向你阐述他如何处理各种explicit（明确出现于C++程序代码中）和implicit（隐藏于程序代码背后）的C++语意。
　　《深度探索C++对象模型》专注于C++面向对象程序设计的底层机制，包括结构式语意、临时性对象的生成、封装、继承，以及虚拟——虚拟函数和虚拟继承。这《深度探索C++对象模型》让你知道：一旦你能够了解底层实现模型，你的程序代码将获得多么大的效率。Lippman澄清了那些关于C++额外负荷与复杂度的各种错误信息和迷思，但也指出其中某些成本和利益交换确实存在。他阐述了各式各样的实现模型，指出它们的进化之道及其本质因素。书中涵盖了C++对象模型的语意暗示，并指出这个模型是如何影响你的程序的。

目录

本立道生（侯捷译序）
前言（StanleyB.Lippman）
第0章导读（译者的话）
第1章关于对象（ObjectLessons）
加上封装后的布局成本（LayoutCostsforAddingEncapsulation）
1.1　C++对象模式（TheC++ObjectModel）
简单对象模型（ASimpleObjectModel）
表格驱动对象模型（ATable-drivenObjectModel）
C++对象模型（TheC++ObjectModel）
对象模型如何影响程序（HowtheObjectModelEffectsPrograms）
1.2关键词所带来的差异（AKeywordDistinction）
关键词的困扰
策略性正确的struct（ThePoliticallyCorrectStruct）
1.3对象的差异（AnObjectDistinction）
指针的类型（TheTypeofaPointer）
加上多态之后（AddingPolymorphism）
第2章构造函数语意学（TheSemanticsofConstructors）
2.1DefaultConstructor的构造操作
“带有DefaultConstructor”的MemberClassObject
“带有DefaultConstructor”的BaseClass
“带有一个VirtualFunction”的Class
“带有一个VirtualBaseClass”的Class
总结
2.2CopyConstructor的构造操作
DefaultMemberwiseInitialization
BitwiseCopySemantics（位逐次拷贝）
不要BitwiseCopySemantics！
重新设定VirtualTable的指针
处理VirtualBaseClassSubobject
2.3程序转化语意学（ProgramTransformationSemantics）
显式的初始化操作（ExplicitInitialization）
参数的初始化（ArgumentInitialization）
返回值的初始化（ReturnValueInitialization）
在使用者层面做优化（OptimizationattheUserLevel）
在编译器层面做优化（OptimizationattheCompilerLevel）
CopyConstructor：要还是不要？
摘要
2.4成员们的初始化队伍（MemberInitializationList）
第3章Data语意学（TheSemanticsofData）
3.1DataMember的绑定（TheBindingofaDataMember）
3.2DataMember的布局（DataMemberLayout）
3.3DataMember的存取
StaticDataMembers
NonstaticDataMembers
3.4“继承”与DataMember
只要继承不要多态（InheritancewithoutPolymorphism）
加上多态（AddingPolymorphism）
多重继承（MultipleInheritance）
虚拟继承（VirtualInheritance）
3.5对象成员的效率（ObjectMemberEfficiency）
3.6指向DataMembers的指针（PointertoDataMembers）
“指向Members的指针”的效率问题
第4章Function语意学（TheSemanticsofFunction）
4.1Member的各种调用方式
NonstaticMemberFunctions（非静态成员函数）
VirtualMemberFunctions（虚拟成员函数）
StaticMemberFunctions（静态成员函数）
4.2VirtualMemberFunctions（虚拟成员函数）
多重继承下的VirtualFunctions
虚拟继承下的VirtualFunctions
4.3函数的效能
4.4指向MemberFunction的指针（Pointer-to-MemberFunctions）
支持“指向VirtualMemberFunctions”的指针
在多重继承之下，指向MemberFunctions的指针
“指向MemberFunctions之指针”的效率
4.5InlineFunctions
形式参数（FormalArguments）
局部变量（LocalVariables）
第5章构造、析构、拷贝语意学（SemanticsofConstruction,
Destruction,andCopy）
纯虚函数的存在（PresenceofaPureVirtualFunction）
虚拟规格的存在（PresenceofaVirtualSpecification）
虚拟规格中const的存在
重新考虑class的声明
5.1“无继承”情况下的对象构造
抽象数据类型（AbstractDataType）
为继承做准备
5.2继承体系下的对象构造
虚拟继承（VirtualInheritance）
vptr初始化语意学（TheSemanticsofthevptrInitialization）
5.3对象复制语意学（ObjectCopySemantics）
5.4对象的效能（ObjectEfficiency）
5.5析构语意学（SemanticsofDestruction）
第6章执行期语意学（RuntimeSemantics）
6.1对象的构造和析构（ObjectConstructionandDestruction）
全局对象（GlobalObjects）
局部静态对象（LocalStaticObjects）
对象数组（ArrayofObjects）
DefaultConstructors和数组
6.2new和delete运算符
针对数组的new语意
PlacementOperatornew的语意
6.3临时性对象（TemporaryObjects）
临时性对象的迷思（神话、传说）
第7章站在对象模型的尖端（OntheCuspoftheObjectModel）
7.1Template
Template的“实例化”行为（TemplateInstantiation）
Template的错误报告（ErrorReportingwithinaTemplate）
Template中的名称决议法（NameResolutionwithinaTemplate）
MemberFunction的实例化行为（MemberFunctionInstantiation）
7.2异常处理（ExceptionHandling）
ExceptionHandling快速检阅
对ExceptionHandling的支持
7.3执行期类型识别（RuntimeTypeIdentification，RTTI）
Type-SafeDowncast（保证安全的向下转换操作）
Type-SafeDynamicCast（保证安全的动态转换）
References并不是Pointers
Typeid运算符
7.4效率有了，弹性呢？
动态共享函数库（DynamicSharedLibraries）
共享内存（SharedMemory）

精彩书摘

　　MemberFunction的实例化行为（MemberFunctionInstantiation）对于template的支持，最困难的莫过于templatefunction的实例化（instantiation）。目前的编译器提供了两个策略：一个是编译时期策略，程序代码必须在programtextfile中备妥可用；另一个是链接时期策略，有一些meta.compilation工具可以导引编译器的实例化行为（instantiation）。
　　下面是编译器设计者必须回答的三个主要问题：
　　1.编译器如何找出函数的定义？
　　答案之一是包含templateprogramtextfile，就好像它是一个header文件一样。
　　Borland编译器就遵循这个策略。另一种方法是要求一个文件命名规则，例如，我们可以要求，在Point.h文件中发现的函数声明，其templateprogramtext一定要放置于文件Point.C或Point.cpp中，依此类推。cfront就遵循这个策略。EdisonDesignGroup编译器对这两种策略都支持。
　　2.编译器如何能够只实例化程序中用到的memberfunctions？
　　解决办法之一就是，根本忽略这项要求，把一个已经实例化的class的所有memberfunctions都产生出来。Borland就是这么做的——虽然它也提供#pragmas让你压制（或实例化）特定实例。另一种策略就是模拟链接操作，检测看看哪一个函数真正需要，然后只为它（们）产生实例。cfront就是这么做的。EdisonDesignGroup编译器对这两种策略都支持。
　　3.编译器如何阻止memberdefinitions在多个.o文件中都被实例化呢？
　　解决办法之一就是产生多个实例，然后从链接器中提供支持，只留下其中一个实例，其余都忽略。另一个办法就是由使用者来导引“模拟链接阶段”的实例化策略，决定哪些实例（instances）才是所需求的。
　　目前，不论是编译时期还是链接时期的实例化（instantiation）策略，均存在以下弱点：当template实例被产生出来时，有时候会大量增加编译时间。很显然，这将是templatefunctions第一次实例化时的必要条件。然而当那些函数被非必要地再次实例化，或是当“决定那些函数是否需要再实例化”所花的代价太大时，编译器的表现令人失望！
　　C++支持template的原始意图可以想见是一个由使用者导引的自动实例化机制（use—directedautomaticinstantiationmechanism），既不需要使用者的介入，也不需要相同文件有多次的实例化行为。但是这已被证明是非常难以达成的任务，比任何人此刻所能想象的还要难（请参考[S7ROUP94]）。ptlink，随着cfront3.0版所附的原始实例化工具，提供了一个由使用者驱动的自动实例化机制（use—drivenautomaticinstantiationmechanism），但它实在太复杂了，即使是久经世故的人也没法一下子了解。
　　……