深度探索C++对象模型

.“带有default constructor”的member class object 41
“带有default constructor”的base class 44
“带有一个virtual function”的class 44
“带有一个virtual base class”的class 46
总结 47
2.2 copy constructor的构造操作 48
default memberwise initialization 49
bitwise copy semantics（位逐次拷贝） 51
不要bitwise copy semantics！ 53
重新设定virtual table的指针 54
处理virtual base class subobject 57
2.3 程序转化语意学（program transformation semantics） 60
显式的初始化操作（explicit initialization） 61
参数的初始化（argument initialization） 62
返回值的初始化（return value initialization） 63
在使用者层面做优化（optimization at the user level） 65
在编译器层面做优化（optimization at the compiler level） 66
copy constructor：要还是不要？ 72
摘要 74
2.4 成员们的初始化队伍（member initialization list） 74
第3章 data语意学（the semantics of data） 83
3.1 data member的绑定（the binding of a data member） 88
3.2 data member的布局（data member layout） 92
3.3 data member的存取 94
static data members 95
nonstatic data members 97
3.4 “继承”与data member 99
只要继承不要多态（inheritance without polymorphism） 100
加上多态（adding polymorphism） 107
多重继承（multiple inheritance） 112
虚拟继承（virtual inheritance） 116
3.5 对象成员的效率（object member efficiency） 124
3.6 指向data members的指针（pointer to data members） 129
“指向members的指针”的效率问题 134
第4章 function语意学（the semantics of function） 139
4.1 member的各种调用方式 140
nonstatic member functions（非静态成员函数） 141
virtual member functions（虚拟成员函数） 147
static member functions（静态成员函数） 148
4.2 virtual member functions（虚拟成员函数） 152
多重继承下的virtual functions 159
虚拟继承下的virtual functions 168
4.3 函数的效能 170
4.4 指向member function的指针（pointer-to-member functions） 174
支持“指向virtual member functions”的指针 176
在多重继承之下，指向member functions的指针 178
“指向member functions之指针”的效率 180
4.5 inline functions 182
形式参数（formal arguments） 185
局部变量（local variables） 186
第5章 构造、析构、拷贝语意学（semantics of construction,
destruction, and copy） 191
纯虚函数的存在（presence of a pure virtual function） 193
虚拟规格的存在（presence of a virtual specification） 194
虚拟规格中const的存在 195
重新考虑class的声明 195
5.1 “无继承”情况下的对象构造 196
抽象数据类型（abstract data type） 198
为继承做准备 202
5.2 继承体系下的对象构造 206
虚拟继承（virtual inheritance） 210
vptr初始化语意学（the semantics of the vptr initialization） 213
5.3 对象复制语意学（object copy semantics） 219
5.4 对象的效能（object efficiency） 225
5.5 析构语意学（semantics of destruction） 231
第6章 执行期语意学（runtime semantics） 237
6.1 对象的构造和析构（object construction and destruction） 240
全局对象（global objects） 242
局部静态对象（local static objects） 247
对象数组（array of objects） 250
default constructors和数组 252
6.2 new和delete运算符 254
针对数组的new语意 257
placement operator new的语意 263
6.3 临时性对象（temporary objects） 267
临时性对象的迷思（神话、传说） 275
第7章 站在对象模型的尖端（on the cusp of the object model） 279
7.1 template 280
template的“实例化”行为（template instantiation） 281
template的错误报告（error reporting within a template） 285
template中的名称决议法（name resolution within a template） 289
member function的实例化行为（member function instantiation） 292
7.2 异常处理（exception handling） 297
exception handling快速检阅 298
对exception handling的支持 303
7.3 执行期类型识别（runtime type identification，rtti） 308
type-safe downcast（保证安全的向下转换操作） 310
type-safe dynamic cast（保证安全的动态转换） 311
references并不是pointers 313
typeid运算符 314
7.4 效率有了，弹性呢？ 318
动态共享函数库（dynamic shared libraries） 318
共享内存（shared memory） 318

.　　对象模型的底层实现机制，在语言层面上是看不出来的——虽然对象模型的语意本身可以使得某些实现品（编译器）比其他实现品更接近自然。例如，virtual function calls，一般而言是通过一个表格（内含virtual functions地址）的索引而决议得知。一定要使用如此的 virtual table 吗？不，编译器可以自由引进其他任何变通做法。如果使用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的指针……）所带来的额外负荷说个清楚。
　　除了我个人回答这封信外，我也把此信转寄给HP的Steve Vinoski；先前我曾与他讨论过C++的效率问题。以下节录自他的回应：
　　过去数年我听过太多与你的同事类似的看法。许多情况下，这些看法是源于对C++事实真相的缺乏了解。在上周，我和一位朋友闲聊，他在一家IC制造厂服务，他说他们不使用C++，因为“它在你的背后做事情”。我连连追问，于是他说根据他的了解，C++调用malloc()和free()而不让程序员知道。这当然不是真的。这是一种所谓的迷思与传说，引导出类似于你的同事的看法……
　　在抽象性和实际性之间找出平衡点，需要知识、经验以及许多思考。C++的使用需要付出许多心力，但是我的经验告诉我，这项投资的回报率相当高。
　　我喜欢把本书想象成是我对那一封读者来信的回答。是的，本书是一个知识陈列库，帮助大家去除围绕在C++四周的迷思与传说。
　　如果C++对象模型的底层机制会因为实现品（编译器）和时间的变动而不同，我如何能够对于任何特定主题提供一般化的讨论呢？静态初始化（Static initialization）可为此提供一个有趣的例子。
　　已知一个class X有着constructor，如下面所示：
　　
　　class X
　　{
　　 friend istream&
　　 operator]]( istream&, X& );
　　public:
　　 X( int sz = 1024 ) { ptr = new char[ sz ]; }
　　 ...
　　private:
　　 char *ptr;
　　};
　　
　　而一个class X的global object的声明，如下面所示：
　　
　　X buf;
　　
　　int main()
　　{
　　 // buf 必须在这个时候构造起来
　　 cin ]] setw( 1024 ) ]] buf;
　　 ...
　　}
　　
　　C++对象模型保证，X constructor将在main()之前便把buf初始化。然而它并没有说明这是如何办到的。答案是所谓的静态初始化（static initialization），实际做法则有赖开发环境对此的支持属于哪一层级。
　　原始的cfront实现品不单只是假想没有环境支持，它也假想没有明确的目标平台。唯一能够假想的平台就是UNIX及其衍化的一些变体。我们的解决之道也因此只专注在UNIX身上：我们使用nm命令。CC命令（一个UNIX shell script）产生出一个可执行文件，然后我们把nm施行于其上，产生出一个新的.c文件。然后编译这个新的.c文件，再重新链接出一个可执行文件（这就是所谓的munch solution）。这种做法是以编译器时间来交换移植性。
　　接下来是提供一个“平台特定”解决之道：直接验证并穿越COFF-based程序的可执行文件（此即所谓的 patch solution），不再需要nm、compile、relink。COFF 是Common Object File Format的缩写，是System V pre-Release 4 UNIX系统所发展出来的格式。这两种解决方案都属于程序层面，也就是说，针对每一个需要静态初始化的.c文件，cfront 会产生出一个sti函数，执行必要的初始化操作。不论是patch solution还是munch solution，都会去寻找以sti开头的函数，并且安排它们以一种未被定义的顺序执行（由安插在main()之后第一行的一个library function _main()执行之）（译注：本书第6章对此有详细说明）。
　　System V COFF-specific C++编译器与cfront的各个版本平行发展。由于瞄准了一个特定平台和特定操作系统，此编译器因而能够影响链接器特地为它修改：产生出一个新的.ini section，用以收集需要静态初始化的objects。链接器的这种扩充方式，提供了所谓的environment-based solution，那当然更在program-based solution层次之上。
　　至此，任何以cfront program-based solution为基础的一般化（泛型）操作将令人迷惑。为什么？因为C++已经成为主流语言，它已经接收了越来越多的environment-based solutions。本书如何维护其间的平衡呢？我的策略如下：如果在不同的C++编译器上有重大的实现技术差异，我就至少讨论两种做法。但如果 cfront之后的编译器实现模型只是解决cfront原本就已理解的问题，例如对虚拟继承的支持，那么我就阐述历史的演化。当我说到“传统模型”时，我的意思是Stroustrup的原始构想（反映在cfront身上），它提供一种实现模范，在今天所有的商业化实现品上仍然可见。
　　本书组织
　　第1章，关于对象（Object Lessons），提供以对象为基础的观念背景，以及由C++提供的面向对象程序设计范式（paradigm。译注：关于paradigm这个字，请参阅本书第1章第22页的译注）。本章包括对对象模型的一个概述，说明目前普及的工业产品，但没有对于多重继承和虚拟继承有太靠近的观察（那是第３章和第４章的重头戏）。
　　第2章，构造函数语意学（The Semantics of Constructors），详细讨论constructor 如何工作。本章谈到constructors何时被编译器合成，以及给你的程序效率带来什么样的意义。
　　第3章至第5章是本书的重要内容。在这里，我详细地讨论了C++对象模型的细节。第3章，Data语意学（The Semantics of Data），讨论data members的处理。第4章，Function语意学（The Semantics of Function），专注于各式各样的member functions，并特别详细地讨论如何支持virtual functions。第5章，构造、析构、拷贝语意学（Semantics of Construction, Destruction, and Copy），讨论如何支持class模型，也讨论到object的生命期。每一章都有测试程序以及测试数据。我们对效率的预测，将拿来和实际结果做比较。
　　第6章，执行期语意学（Runtime Semantics），查看执行期的某些对象模型行为。包括临时性对象的生命及其死亡，以及对new运算符和delete运算符的支持。
　　第7章，在对象模型的尖端（On the Cusp of the Object Model），专注于exception handling、template support、runtime type identification。
　　预定的读者
　　本书可以扮演家庭教师的角色，不过它定位在中级以上的C++程序员，而非C++新手。我尝试提供足够的内容，使它能够被任何有点C++基础（例如读过我的C++ Primer并有一些实际编程经验）的人接受。理想的读者是，曾经有过数年的C++编程经验，希望进一步了解“底层做些什么事”的人。书中某些部分甚至对于C++高手也具有吸引力，如临时性对象的产生，以及named return value（NRV）最佳化的细节等等。在与本书素材相同的各个公开演讲场合中，我已经证实了这些材料的吸引力。
　　程序范例及其执行
　　本书的程序范例主要有两个目的：
　　1. 为了提供书中所述C++对象模型各种概念的具体说明。
　　2. 提供测试，以测量各种语言性质的相对成本。
　　无论哪一种意图，都只是为了展现对象模型。举例而言，虽然我在书中有大量的举例，但我并非建议一个真实的3D graphic library必须以虚拟继承的方式来表现一个3D点（不过，你可以在[POKOR94]中发现作者Pokorny的确是这么做的）。
　　
　　书中所有测试程序都在一部SGI Indigo2xL上编译执行，使用SGI 5.2 UNIX操作系统中的CC和NCC编译器。CC是cfront 3.0.1版（它会产生出C代码，再由一个C编译器重新编译为可执行文件）。NCC是Edison Design Group的C++ front-end 2.19版，内含一个由SGI供应的程序代码产生器。至于时间测量，是采用UNIX的timex命令针对1 000万次迭代测试所得的平均值。
　　虽然在xL机器上使用这两个编译器，对读者而言可能觉得有些神秘，我却觉得对此书的目的而言，很好。不论是cfront或现在的Edison Design Group's C++ front-end（Bjarne称其为“cfront的儿子”），都与平台无关。它们是一种一般化的编译器，被授权给34家以上的计算机制造商（其中包括Gray、SGI、Intel）和软件开发环境厂商（包括Centerline和Novell，后者是原先的UNIX软件实验室）。效率的测量并非为了对目前市面上的各家编译系统做评比，而只是为了提供C++对象模型之各种特性的一个相对成本测量。至于商业评比的效率数据，你可以在几乎任何一本计算机杂志的计算机产品检验报告中获得。