深度探索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 对象模型深度探索。虽然只是说是浅尝即止，但也有不少收获。我会再写一个完结篇，写写感受。以呼应开头。有始有终吗。假如有兴趣能够看看

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有