深度探索C++对象模型（10）

介绍

　　我们完成了一次C++对象模型深度探索。虽然只是说是浅尝即止，但也有不少收获。

　　雷神使劲的搓搓手（心情激动，好象按F5之前的感觉，同时北京的天气太冷了，手脚冰凉），翻开了《深度探索C++对象模型》最后一章。On the Cusp of the Object Model.。首先浏览了一遍本章，噢，这章为我们解释了三个C++的特性，模板类，异常，运行时类型识别，同时还顺便说了一些以前很模糊的概念，例如引用和指针的区别。好了让我们开始最后的冲刺。

　　Template最初是为了对lists和Arrays提供支持，但是现在它已经成为了Standard Template Library,STL的基础了。它也被用于属性混合或者互斥机制中。（雷神隐隐感到C#的装箱和拆箱的底层也是由Template实现，当然肯定C#底层用了大量的Template，但是BOX是我的第一反应J）。我们先来声明一个Template class见下：

template ＜class Type＞
class Point
{
public:
enum Status{unallocated,normalized};
Point(Type x=0.0, Type y=0.0, Type z=0.0);
~Point();

void* operator new(size_t);
void operator delete(void*,size_t);
//……
private:
static Point＜Type＞ *freeList;
static int chunkSize;
Type _x, _y,_z;
};

　　当编译看到这个Template class声明时，没有任何反应。这个很好理解因为编译器还不知道到底要为Template class的对象分配多少内存大小，因为它是Template class。所以编译器什么都不做。它的成员也不能直接调用，我们只能通过Template class的某个实体对象来存取操作，向下面这样。

　　Point＜float＞::Status s
　　什么时候编译器会真正的实现出一个实体对象呢？我们来看三种情况：

　　1、 const Point＜float＞ origin;
　　这个是秃子头上的虱子，明摆着的，肯定会产生一个实体对象。

　　2、 const Point＜float＞ &ref=0;
　　它会被内部扩展为：
　　Point＜float＞ temporary(float(0));//在着里已经产生一个临时的对象。
　　const Point＜float＞ &ref=temporary;
　　因此这样也可以产生，只不过是编译器暗中实现的。

　　3、 Point＜float＞ *ptr=0;
　　这个也简单，肯定是没有实体对象产生。因为指向类对象的指针并不是一个对象，这行代码并不能告诉编译器于该类有关的信息，如数据成员，或者对象的数据布局。因此这样写编译器也不会干活。

　　新的问题来了。一个类有很多的成员函数，并且你很可能不会都使用到它们，因此编译器应该在使用这个成员函数时，才将它实体化。这样才能保证效率。目前的编译器提供了两个策略，一个是编译时期策略，一个是链接时期策略。

　　具体的做法如下：

　　1、包含template program text file，就好象是头文件，Borland遵循这一策略。我们要求Point.h中发现的函数声明的template program text file放置在Point.h或Point.cpp中。这样编译器可以找出函数的定义。
　　2、把一个类的所有成员函数都产生出来。Borland遵循这一策略（这样其不丧失了些效率？它通过#pragmas来压制特定实体）。或者仿真链接操作，检测哪个函数真正需要，然后产生实体。这样做可以只具体实现程序中用到的成员函数。
　　3、后为了阻止成员的定义在对个对象文件中都被具现，做法是产生多个实体，然后通过链接器只留下一个实体。或者由使用者引导仿真链接阶段，决定哪些实体是需要的。

　　书上还介绍了Edison的编译器机制，很符合template的原始涵义，主要过程如下：

　　1、一个程序的代码被编译，不会产生template的具现体，但相关信息已经产生于对象文件。
　　2、当对象文件被链接时，会有一个prelinker程序执行，它会检查对象文件，寻找template实体的相互参考和对应的定义。
　　3、对于每一个参考到template实体，但实体未被定义时，prelinker把它视为与另一个文件同类。Prelinker会生成一个.ii文件用来记录检测结果。
　　4、prelinker重新执行编译器，重新编译每一个被改变了的.ii文件，不断重复此操作，直到所有的必要实现都已完成。
　　5、所有的对象文件被链接成一个可执行文件。

　　所以可以看出目前的编译器在template实体产生时会增加大量的编译时间。

　　异常处理相对简单，大家在平时的写代码时肯定会大量的用到。加入异常可以提高程序的健壮，并且可以在调式代码时获得帮助，例如你可以将你需要的信息throw出来。站在编译器的角度，主要工作是找到catch子句，处理被抛出的异常情况。完成这一工作，编译器需要利用RTTI机制来识别和查询异常对象的类型，还要有一个机制管理被抛出的异常对象。一般来说异常处理需要与编译器所产生的数据结构和执行期的一个异常库紧密合作。这样做势必也会影响程序的大小和执行速度。当我们编译代码时，编译器（VC）会让我们来进行选择，是要速度还是要大小，其实取决与在编译时期所建立的支持数据结构。好了这个问题就不多说了。

　　在面向对象的编程中多态的数据类型被大量的应用，同时还有很多内建的或者非多态的数据类型，多态肯定会需要一些额外的负担，例如：因为需要大量的downcast操作，所以需要一个空间存储类型信息，通常是一个指向类型信息节点的指针。如何保证这两种不同的类型都能获得最合适的空间和效率呢。这也是编译器需要做的事情。(RTTI,Runtime Type Identification)do执行期类型识别便是解决这一问题的方法。

　　C++的RTTI机制提供一个安全的downcast设备，只对多态的类型有效。如何一眼便能看出这个类是否是一个独立的ADT或者是一个支持多态的可继承的子类呢？计算机没有照妖镜，也没有火眼金睛。只能由我们为他提供一个策略，或者说是判断的标准。这个问题在前面已经研究过了，一个具备多态性质的class，肯定含有继承或者直接声明的一个或者多个虚函数。编译器知道了这个类是否是多态后会将，与这个类相关的RTTI对象地址放进这个对象的虚函数表中。这样一来一个对象只需要多一个指针而已。我们的额外负担被降到了最低。

　　好了，就到这里吧。我们完成了一次C++对象模型深度探索。虽然只是说是浅尝即止，但也有不少收获。我会再写一个完结篇，写写感受。以呼应开头。有始有终吗。如果有兴趣可以看看。