转自：http://blog.csdn.net/mannhello/article/details/5217954

RTTI 是“Runtime Type Information”的缩写，意思是：运行时类型信息。它提供了运行时确定对象类型的方法。本文将简略介绍 RTTI 的一些背景知识、描述 RTTI 的概念，并通过具体例子和代码介绍什么时候使用以及如何使用 RTTI；本文还将详细描述两个重要的 RTTI 运算符的使用方法，它们是 typeid 和 dynamic_cast。
其实，RTTI 在C++中并不是什么新的东西，它早在十多年以前就已经出现了。但是大多数开发人员，包括许多高层次的C++程序员对它并不怎么熟悉，更不用说使用 RTTI 来设计和编写应用程序了。
一些面向对象专家在传播自己的设计理念时，大多都主张在设计和开发中明智地使用虚拟成员函数，而不用 RTTI 机制。但是，在很多情况下，虚拟函数无法克服本身的局限。每每涉及到处理异类容器和根基类层次（如 MFC）时，不可避免要对对象类型进行动态判断，也就是动态类型的侦测。如何确定对象的动态类型呢？答案是使用内建的 RTTI 中的运算符：typeid 和 dynamic_cast。
首先让我们来设计一个类层次，假设我们创建了某个处理文件的抽象基类。它声明下列纯虚拟函数：open()、close()、read()和 write()：

class File
{
public:
virtual int open(const string & filename)=0;
virtual int close(const string & filename)=0;
//
virtual ~File()=0; // 记住添加纯虚拟析构函数（dtor）
};
现在从 File 类派生的类要实现基类的纯虚拟函数，同时还要提供一些其他的操作。假设派生类为 DiskFile，除了实现基类的纯虚拟函数外，还要实现自己的flush()和defragment()操作： class DiskFile: public File
{
public:
int open(const string & filename);

// 实现其他的纯虚拟函数
......

// 自己的专有操作
virtual int flush();
virtual int defragment();
};
接着，又从 DiskFile 类派生两个类，假设为 TextFile 和 MediaFile。前者针对文本文件，后者针对音频和视频文件： class TextFile: public DiskFile
{
// ......
int sort_by_words();
};

class MediaFile: public DiskFile
{
//......
};
我们之所以要创建这样的类层次，是因为这样做以后可以创建多态对象，如：File *pfile; // *pfile的静态类型是 File
if(some_condition)
pfile = new TextFile; // 动态类型是 TextFile
else
pfile = new DiskFile; // 动态类型是 DiskFile
假设你正在开发一个基于图形用户界面（GUI）的文件管理器，每个文件都可以以图标方式显示。当鼠标移到图标上并单击右键时，文件管理器打开一个菜单，每个文件除了共同的菜单项，不同的文件类型还有不同的菜单项。如：共同的菜单项有“打开”“拷贝”、和“粘贴”，此外，还有一些针对特殊文件的专门操作。比如，文本文件会有“编辑”操作，而多媒体文件则会有“播放”菜单。为了使用 RTTI 来动态定制菜单，文件管理器必须侦测每个文件的动态类型。利用 运算符 typeid 可以获取与某个对象关联的运行时类型信息。typeid 有一个参数，传递对象或类型名。因此，为了确定 x 的动态类型是不是Y，可以用表达式：typeid(x) == typeid(Y)实现：#include <typeinfo> // typeid 需要的头文件
void menu::build(const File * pfile)
{
if (typeid(*pfile)==typeid(TextFile))
{
add_option("edit");
}
else if (typeid(*pfile)==typeid(MediaFile))
{
add_option("play");
}
}
使用 typeid 要注意一个问题，那就是某些编译器（如 Visual C++）默认状态是禁用 RTTI 的，目的是消除性能上的开销。如果你的程序确实使用了 RTTI，一定要记住在编译前启用 RTTI。使用 typeid 可能产生一些将来的维护问题。假设你决定扩展上述的类层次，从MediaFile 派生另一个叫 LocalizeMedia 的类，用这个类表示带有不同语言说明文字的媒体文件。但 LocalizeMedia 本质上还是个 MediaFile 类型的文件。因此，当用户在该类文件图标上单击右键时，文件管理器必须提供一个“播放”菜单。可惜 build()成员函数会调用失败，原因是你没有检查这种特定的文件类型。为了解决这个问题，你必须象下面这样对 build() 打补丁： void menu::build(const File * pfile)
{

//......

else if (typeid(*pfile)==typeid(LocalizedMedia))
{
add_option("play");
}
}
唉，这种做法真是显得太业余了，以后每次添加新的类，毫无疑问都必须打类似的补丁。显然，这不是一个理想的解决方案。这个时候我们就要用到 dynamic_cast，这个运算符用于多态编程中保证在运行时发生正确的转换（即编译器无法验证是否发生正确的转换）。用它来确定某个对象是 MediaFile 对象还是它的派生类对象。dynamic_cast 常用于从多态编程基类指针向派生类指针的向下类型转换。它有两个参数：一个是类型名；另一个是多态对象的指针或引用。其功能是在运行时将对象强制转换为目标类型并返回布尔型结果。也就是说，如果该函数成功地并且是动态的将 *pfile 强制转换为 MediaFile，那么 pfile的动态类型是 MediaFile 或者是它的派生类。否则，pfile 则为其它的类型：void menu::build(const File * pfile)
{
if (dynamic_cast <MediaFile *> (pfile))
{
// pfile 是 MediaFile 或者是MediaFile的派生类 LocalizedMedia
add_option("play");
}
else if (dynamic_cast <TextFile*> (pfile))
{
// pfile 是 TextFile 是TextFile的派生类
add_option("edit");
}
}
细细想一下，虽然使用 dynamic_cast 确实很好地解决了我们的问题，但也需要我们付出代价，那就是与 typeid 相比，dynamic_cast 不是一个常量时间的操作。为了确定是否能完成强制类型转换，dynamic_cast`必须在运行时进行一些转换细节操作。因此在使用 dynamic_cast 操作时，应该权衡对性能的影响

第二章

typeid和RTTI C++- -

Tag： typeid和RTTI    C++                                          

观点有一些值得商榷的地方

关于typeid和RTTI的问答
问：在c++里怎么能知道一个变量的具体类型，如：c#里的typeof.还有我怎么知道一个变量的类型是某个类型的子类，也就是实现关键字IS

答：
1。运行时获知变量类型名称，可以使用 typeid(变量).name，需要注意不是所有编译器都输出"int"、"float"等之类的名称，对于这类的编译器可以这样使用：float f = 1.1f; if( typeid(f) == typeid(0.0f) ) ……
2。对于多态类实例，想得到实际的类名称，需要使用到RTTI，这需要在编译的时候加上参数"/GR"。
3。对于普通变量，既然是自己写的，那当然也就应该知道它的类型，其实用不着运行时获知；对于多态类实例，既然需要运行时获知实际类型，那么就说明这里不具有多态性，既然没有多态性就不应该抽象它，这属于设计错误，总之，我认为RTTI是多余的。
4。对于多态类实例，使用 typeid(value) == typeid(value)来判断，不如使用 dynamic_cast 来判断，它们的原理是一样的。

事例代码：
#include
using namespace std;
int main( void )
{
// sample 1
    cout << typeid(1.1f).name() << endl;
// sample 2
    class Base1
    {
    };
    class Derive1 : public Base1
    {
    };
    Derive1 d1;
    Base1& b1 = d1;
    cout << typeid(b1).name() << endl; // 输出"class Base1",因为Derive1和Base1之间没有多态性
// sample 3, 编译时需要加参数 /GR
    class Base2
    {
        virtual void fun( void ) {}
    };
    class Derive2 : public Base2
    {
    };
    Derive2 d2;
    Base2& b2 = d2;
    cout << typeid(b2).name() << endl; // 输出"class Derive2",因为Derive1和Base1之间有了多态性
// sample 4
    class Derive22 : public Base2
    {
    };
    // 指针强制转化失败后可以比较指针是否为零，而引用却没办法，所以引用制转化失败后抛出异常
    Derive2* pb1 = dynamic_cast(&b2);
    cout << boolalpha << (0!=pb1) << endl; // 输出"true",因为b2本身就确实是Derive2
    Derive22* pb2 = dynamic_cast(&b2);
    cout << boolalpha << (0!=pb2) << endl; // 输出"true",因为b2本身不是Derive2

    try {
        Derive2& rb1 = dynamic_cast<DERIVE2& />(b2);
        cout << "true" << endl;
    } catch( bad_cast )
    {
        cout << "false" << endl;
    }
    try {
        Derive22& rb2 = dynamic_cast<DERIVE22& />(b2);
        cout << "true" << endl;
    } catch( ... ) // 应该是 bad_cast,但不知道为什么在VC++6.0中却不行
    {
        cout << "false" << endl;
    }

    return 0;
}

posted on 2004-09-13 22:45 周星星 阅读(2278) 评论(9)  编辑 收藏

/////////////////////////////////////////////
MFC六大关键技术之运行时类型识别
运行时类型识别（RTTI）即是程序执行过程中知道某个对象属于某个类，我们平时用C++编程接触的RTTI一般是编译器的RTTI

运行时类型识别（RTTI）即是程序执行过程中知道某个对象属于某个类，我们平时用C++编程接触的RTTI一般是编译器的RTTI，即是在新版本的VC++编译器里面选用“使能RTTI”，然后载入typeinfo.h文件，就可以使用一个叫typeid（）的运算子，它的地位与在C++编程中的sizeof()运算子类似的地方（包含一个头文件，然后就有一个熟悉好用的函数）。typdid()关键的地方是可以接受两个类型的参数：一个是类名称，一个是对象指针。所以我们判别一个对象是否属于某个类就可以象下面那样：

if （typeid (ClassName)== typeid（*ObjectName））{
((ClassName*)ObjectName)->Fun();
}

　　象上面所说的那样，一个typeid（）运算子就可以轻松地识别一个对象是否属于某一个类，但MFC并不是用typeid（）的运算子来进行动态类型识别，而是用一大堆令人费解的宏。很多学员在这里很疑惑，好象MFC在大部分地方都是故作神秘。使们大家编程时很迷惘，只知道在这里加入一组宏，又在那儿加入一个映射，而不知道我们为什么要加入这些东东。

　　其实，早期的MFC并没有typeid（）运算子，所以只能沿用一个老办法。我们甚至可以想象一下，如果MFC早期就有template（模板）的概念，可能更容易解决RTTI问题。

　　所以，我们要回到“古老”的年代，想象一下，要完成RTTI要做些什么事情。就好像我们在一个新型（新型到我们还不认识）电器公司里面，我们要识别哪个是电饭锅，哪个是电磁炉等等，我们要查看登记的各电器一系列的信息，我们才可以比较、鉴别，那个东西是什么！
要登记一系列的消息并不是一件简单的事情，大家可能首先想到用数组登记对象。但如果用数组，我们要定义多大的数组才好呢，大了浪费空间，小了更加不行。所以我们要用另一种数据结构——链表。因为链表理论上可大可小，可以无限扩展。

　　链表是一种常用的数据结构，简单地说，它是在一个对象里面保存了指向下一个同类型对象的指针。我们大体可以这样设计我们的类：

struct CRuntimeClass
{
……类的名称等一切信息……
CRuntimeClass * m_pNextClass;//指向链表中下一CRuntimeClass对象的指针
};

　　链表还应该有一个表头和一个表尾，这样我们在查链表中各对象元素的信息的时候才知道从哪里查起，到哪儿结束。我们还要注明本身是由哪能个类派生。所以我们的链表类要这样设计：

struct CRuntimeClass
{
……类的名称等一切信息……
CRuntimeClass * m_pBaseClass;//指向所属的基类。
CRuntimeClass * m_pNextClass;//定义表尾的时候只要定义此指针为空就可以 了。
static CRuntimeClass* pFirstClass;//这里表头指针属于静态变量，因为我们知道static变量在内存中只初始化一次，就可以为各对象所用！保证了各对象只有一个表头。
};

　　有了CRuntimeClass结构后，我们就可以定义链表了：

static CRuntimeClass classCObject={NULL,NULL};//这里定义了一个CRuntimeClass对象，

　　因为classCObject无基类，所以m_pBaseClass为NULL。因为目前只有一个元素（即目前没有下一元素），所以m_pNextClass为NULL（表尾）。

　　至于pFirstClass（表头），大家可能有点想不通，它到什么地方去了。因为我们这里并不想把classCObject作为链表表头，我们还要在前面插入很多的CRuntimeClass对象，并且因为pFirstClass为static指针，即是说它不是属于某个对象，所以我们在用它之前要先初始化：

CRuntimeClass* CRuntimeClass：：pFirstClass=NULL;

　　现在我们可以在前面插入一个CRuntimeClass对象，插入之前我得重要申明一下：如果单纯为了运行时类型识别，我们未必用到m_pNextClass指针（更多是在运行时创建时用），我们关心的是类本身和它的基类。这样，查找一个对象是否属于一个类时，主要关心的是类本身及它的基类：

CRuntimeClass classCCmdTarget={ &classCObject, NULL};
CRuntimeClass classCWnd={ &classCCmdTarget ,NULL };
CRuntimeClass classCView={ &classCWnd , NULL };

　　好了，上面只是仅仅为一个指针m_pBaseClass赋值（MFC中真正CRuntimeClass有多个成员变量和方法），就连接成了链表。假设我们现在已全部构造完成自己需要的CRuntimeClass对象，那么，这时候应该定义表头。即要用pFirstClass指针指向我们最后构造的CRuntimeClass对象——classCView。

CRuntimeClass：：pFirstClass=&classCView;

　　现在链表有了，表头表尾都完善了，问题又出现了，我们应该怎样访问每一个CRuntimeClass对象？要判断一个对象属于某类，我们要从表头开始，一直向表尾查找到表尾，然后才能比较得出结果吗。肯定不是这样！

　　大家可以这样想一下，我们构造这个链表的目的，就是构造完之后，能够按主观地拿一个CRuntimeClass对象和链表中的元素作比较，看看其中一个对象中否属于你指定的类。这样，我们需要有一个函数，一个能返回自身类型名的函数GetRuntimeClass()。

　　上面简单地说一下链表的过程，但单纯有这个链表是没有任何意义。回到MFC中来，我们要实现的是在每个需要有RTTI能力的类中构造一个CRuntimeClass对象，比较一个类是否属于某个对象的时候，实际上只是比较CRuntimeClass对象。

　　如何在各个类之中插入CRuntimeClass对象，并且指定CRuntimeClass对象的内容及CRuntimeClass对象的链接，这里起码有十行的代码才能完成。在每个需要有RTTI能力的类设计中都要重复那十多行代码是一件乏味的事情，也容易出错，所以MFC用了两个宏代替这些工作，即DECLARE_DYNAMIC(类名)和IMPLEMENT_DYNAMIC(类名，基类名)。从这两个宏我们可以看出在MFC名类中的CRuntimeClass对象构造连接只有类名及基类名的不同！

　　到此，可能会有朋友问：为什么要用两个宏，用一个宏不可以代换CRuntimeClass对象构造连接吗？个人认为肯定可以，因为宏只是文字代换的游戏而已。但我们在编程之中，头文件与源文件是分开的，我们要在头文件头声明变量及方法，在源文件里实具体实现。即是说我们要在头文件中声明：

public:
static CRuntimeClass classXXX //XXX为类名
virtual CRuntime* GetRuntimeClass() const;

　　然后在源文件里实现：

CRuntimeClass* XXX：：classXXX={……}；
CRuntime* GetRuntimeClass() const;

{ return &XXX:: classXXX;}//这里不能直接返回&classXXX，因为static变量是类拥有而不是对象拥有。

　　我们一眼可以看出MFC中的DECLARE_DYNAMIC(类名)宏应该这样定义：

#define DECLARE_DYNAMIC(class_name) public: static CRuntimeClass class##class_name;
virtual CRuntimeClass* GetRuntimeClass() const;

　　其中##为连接符，可以让我们传入的类名前面加上class，否则跟原类同名，大家会知道产生什么后果。

　　有了上面的DECLARE_DYNAMIC(类名)宏之后，我们在头文件里写上一句：

DECLARE_DYNAMIC(XXX)

　　宏展开后就有了我们想要的：

public:
static CRuntimeClass classXXX //XXX为类名
virtual CRuntime* GetRuntimeClass() const;

　　对于IMPLEMENT_DYNAMIC(类名，基类名)，看来也不值得在这里代换文字了，大家知道它是知道回事，宏展开后为我们做了什么，再深究真是一点意义都没有！

　　有了此链表之后，就像有了一张存放各类型的网，我们可以轻而易举地RTTI。CObject有一个函数BOOL IsKindOf(const CRuntimeClass* pClass) const;，被它以下所有派生员继承。

　　此函数实现如下：

BOOL CObject::IsKindOf(const CRuntimeClass* pClass) const
{
CRuntimeClass* pClassThis=GetRuntimeClass();//获得自己的CRuntimeClass对象指针。
while(pClassThis!=NULL)
{
if(pClassThis==pClass) return TRUE;
pClassThis=pClassThis->m_pBaseClass;//这句最关键，指向自己基类，再回头比较，一直到尽头m_pBaseClass为NULL结束。
}
return FALSE;
}

　　说到这里，运行时类型识别（RTTI）算是完成了。写这篇文章的时候，我一直重感冒。我曾一度在想，究竟写这东西是为了什么。因为如果我把这些时间用在别的地方（甚至帮别人打打字），应该有数百元的报酬。

　　是什么让“嗜财如命”的我继续写下去？我想，无非是想交几个计算机的朋友而已。计算机是大家公认高科技的东西，但学习它的朋友大多只能默默无闻，外界的朋友也不知道怎么去认识你。程序员更不是“潮流”的东西，更加得不到别人的认可。

　　有一件个人认为很典型的事情，有一天，我跟一个朋友到一个单位里面。里面有一个女打字员。朋友看着她熟练的指法，心悦诚服地说：“她的电脑水平比你的又高了一个很高的层次！”，那个女的打字高手亦自豪地说：“我靠电脑为生，电脑水平肯定比你（指笔者）的好一点！换着是你，如果以电脑为生，我也不敢说好过你！”。虽然我想声明我是计算机专业的，但我知道没有理解，所以我只得客气地点头。

　　选择电脑“潮流”的东西实际是选择了平凡，而选择做程序员就是选择了孤独！幸好我不是一个专门的程序员，但即使如此，我愿意做你们的朋友，因为我爱你们！

http://www.yesky.com/SoftChannel/72342371928702976/20050228/1915827.shtml

///////////////////////////////
首先，很不好意思的说明，我还正在看C++ language programming，但还没有看到关于RTTI的章节。另外，我也很少使用C++ RTTI的特性。所以对RTTI的理解仅限于自己的摸索和思考。如果不正确，请大家指正。

      RTTI特性是C++语言加入较晚的特性之一。和其他语言（比如JAVA）相比，C++的RTTI能力算是非常差的。这与C++的设计要求应该有重要的关系：性能。没错，性能的因素使得C++的很多地方不能称的上完美，但是也正因为如此，在高级通用语言里面，只有C能和C++的性能可以相提并论。

1：typeid的研究

     在C++中，似乎与RTTI相关的只有一个东西，就是dynamic_cast，本来我认为typeid是RTTI的一部分，但是我的实验表明，并非如此。typeid的操作是在编译时期就已经决定的了。下面的代码可以证明：

#include
#include

class A
{
};

class B:public A
{
};

int main()
{
   A *pa;
   B b,*pb;
   pb = &b;
   pa = pb;
   std::cout<<"Name1:"
        << (typeid(pa).name())
        <<"/tName2:"
        <<(typeid(pb).name())
        <<:endl;< p=""></:ENDL;<>

   std::cout<<"pa == pb:"<< (typeid(pa) == typeid(pb))<<:endl;
   return 0;
}

typeid根本不能判别pa实际上是一个B*。换句话说，typeid是以字面意思去解释类型，不要指望它能认出一个void*实际上是int*(这个连人也做不到:P）。实际上实用价值不大。

当然，在某些特殊地方，也是能够有些效用的，比如模板。

template
void test(T t)
{
 if(typeid(t) == typeid(char *))
 {
   // 对char *特殊处理
 }
 //...
}

如果编译器优化的好的话，并不会产生废代码，因为typeid编译时期就可以决定了。

2：dynamic_cast

    抱歉现在才讲到正题，我对dynamic_cast第一印象就是，它究竟是怎么实现的呢？经过一些思考，我认为最简单的方案就是将信息保存在vtable里，它会占用一个vtalbe表的项目。实验和书籍也证明了这一点。但是就会有一个问题，没有vtable的类怎么办？内建类型怎么办？其实，没有vtable的类，它不需要多态，它根本就不需要RTTI，内建类型也一样。这就是说，dynamic_cast只支持有虚函数的类。而且， dynamic_cast不能进行non_base_class *到 class T*的转换，比如void * --> class T *，因为它无法去正确获得vtable。

     这样，dynamic_cast的意义和使用方法就很清楚了，它是为了支持多态而存在的。它用于实现从基类到派生类的安全转换。同时它也在绝大多数情况下避免了使用static_cast－－不安全的类型转换。

3:结论

    C++ 的RTTI机制虽然简单，或者说简陋，但是它使得静态类型转换变得无用了。这也是C++的一个不可缺少的机制。在未来，如果C++能够提供可选的更强的RTTI机制，就像JAVA里的那样，这种语言可以变得更加强大。当然，到时如何提供不损失性能的 RTTI机制，更是一个值得深入研究的话题了。

第三章

摘要：

　　RTTI(Run-Time Type Identification)是面向对象程序设计中一种重要的技术。现行的C++标准对RTTI已经有了明确的支持。不过在某些情况下出于特殊的开发需要，我们需要自己编码来实现。本文介绍了一些关于RTTI的基础知识及其原理和实现。

RTTI需求：

　　和很多其他语言一样，C++是一种静态类型语言。其数据类型是在编译期就确定的，不能在运行时更改。然而由于面向对象程序设计中多态性的要求，C++中的指针或引用(Reference)本身的类型，可能与它实际代表(指向或引用)的类型并不一致。有时我们需要将一个多态指针转换为其实际指向对象的类型，就需要知道运行时的类型信息，这就产生了运行时类型识别的要求。

　　C++对RTTI的支持：

　　C++提供了两个关键字typeid和dynamic_cast和一个type_info类来支持RTTI：

　　dynamic_cast操作符：它允许在运行时刻进行类型转换，从而使程序能够在一个类层次结构安全地转换类型。dynamic_cast提供了两种转换方式，把基类指针转换成派生类指针，或者把指向基类的左值转换成派生类的引用。见下例讲述：

　　这里bonus是programmer的成员函数，基类employee不具备这个特性。所以我们必须使用安全的由基类到派生类类型转换，识别出programmer指针。

　　typeid操作符：它指出指针或引用指向的对象的实际派生类型。

　　例如：

　　typeid可以用于作用于各种类型名，对象和内置基本数据类型的实例、指针或者引用，当作用于指针和引用将返回它实际指向对象的类型信息。typeid的返回是type_info类型。

　　type_info类：这个类的确切定义是与编译器实现相关的，下面是《C++ Primer》中给出的定义(参考资料[2]中谈到编译器必须提供的最小信息量)：

实现目标：

　　实现的方案

　　方案一：利用多态来取得指针或应用的实际类型信息

　　这是一个最简单的方法，也是作者目前所采用的办法。

　　实现：

　　示例：

　　输出：

　　这种实现方法也就是在基类中提供一个多态的方法，这个方法返回一个类型信息。这样我们能够知道一个指针所指向对象的具体类型，可以满足一些简单的要求。

　　但是很显然，这样的方法只实现了typeid的部分功能，还存在很多缺点：

　　1、 用户每增加一个类必须覆盖GetClassName和TypeOfClass两个方法，如果忘了，会导致程序错误。

　　2、 这里的类名和类标识信息不足以实现dynamic_cast的功能，从这个意义上而言此方案根本不能称为RTTI。

　　3、 用户必须手工维护每个类的类名与标识，这限制了以库的方式提供给用户的可能。

　　4、 用户必须手工添加GetClassName和TypeOfClass两个方法，使用并不方便。

　　其中上面的部分问题我们可以采用C/C++中的宏技巧(Macro Magic)来解决，这个可以在我们的最终解决方案的代码中看到。下面采用方案二中将予以解决上述问题。

上

方案二：以一个类型表来存储类型信息

　　这种方法考虑使用一个类结构，除了保留原有的整型类ID，类名字符串外，增加了一个指向基类TypeInfo成员的指针。

　　从这里可以看到，以这种方式实现的RTTI不支持多重继承。所幸多重继承在程序设计中并非必须，而且也不推荐。下面的代码中，我将为DP9900软件项目组中类层次结构中的几个类添加RTTI功能。DP9900项目中，绝大部分的类都以单继承方式从UObject这个根类直接或间接继承而来。这样我们就可以从UObject开始，加入我们RTTI支持所需要的数据和方法。

　　考虑从UObject将这个TypeInfo类作为每一个新增类的静态成员，这样一个类的所有对象将共享TypeInfo的唯一实例。我们希望能够在程序运行之前就为type_id,className做好初始化，并让pBaseClass指向基类的这个TypeInfo。

　　每个类的TypeInfo成员约定使用rttiTypeInfo的命名，为了避免命名冲突，我们将其作为private成员。有了基类的支持并不够，当用户需要RTTI支持，还需要自己来做一些事情：

　　1、 派生类需要从UObject继承。

　　2、 添加rttiTypeInfo变量。

　　3、 在类外正确初始化rttiTypeInfo静态成员。

　　4、 覆盖GetTypeID、GetTypeName、GetTypeInfo、GetTypeInfoClass四个成员函数。

　　如下所示：

　　有了前三步，这样我们就可以得到一个不算太复杂的链表――这是一棵类型信息构成的"树"，与数据结构中的树的唯一差别就是其指针方向相反。

　　这样，从任何一个UObject的子类，顺着pBaseClass往上找，总能遍历它的所有父类，最终到达UObject。

　　在这个链表的基础上，要判别某个对象是否属于某一个类就很简单。下面给出UObject::IsKindOf()的实现。

　　有了IsKindOf的支持，dynamic_cast的功能也就可以用一个简单的safe_cast来实现：

　　至此，我们已经能够从功能上完成前面的目标了，不过用户要使用这个类库的RTTI功能还很麻烦，要敲入一大堆对他们毫无意义的函数代码，要在初始化rttiTypeInfo静态成员时手工设置类ID与类名。其实这些麻烦完全不必交给我们的用户，适当采用一些宏技巧(Macro Magic)，就可以让C++的预处理器来替我们写很多枯燥的代码。关于宏不是本文的重点，你可以从最终代码清单看到它们。下面再谈谈关于类ID的问题。

　　类ID

　　为了使不同类型的对象可区分，用一个给每个TypeInfo对象一个类ID来作为比较的依据是必要的。
其实对于我们这里的需求和实现方法而言，其实类ID并不是必须的。每一个支持RTTI的类都包含了一个静态TypeInfo对象，这个对象的地址就是在进程中全局唯一。但考虑到其他一些技术如：动态对象创建、对象序列化等，它们可能会要求RTTI给出一个静态不变的ID。在本文的实现中，对此作了有益的尝试。

　　首先声明一个用来产生递增类ID的全局变量。再声明如下一个结构，没有数据成员，只有一个构造函数用于初始化TypeInfo的类ID：

　　为UObject添加一个private的静态成员及其初始化：

　　并且对每一个从UObject派生的子类也进行同样的添加。这样您将看到，在C++主函数执行前，启动代码将替我们调用每一个类的initClassInfo成员的构造函数InitTypeInfo::InitTypeInfo(TypeInfo* info)，而正是这个函数替我们产生并设置了类ID。InitTypeInfo的构造函数还可以替我们做其他一些有用的初始化工作，比如将所有的TypeInfo信息登录到一个表格里，让我们可以很方便的遍历它。

　　但实践与查阅资料让我们发现，由于C++中对静态成员初始化的顺序没有明确的规定，所以这样的方式产生出来的类ID并非完全静态，换一个编译器编译执行产生的结果可能完全不同。

　　还有一个可以考虑的方案是采用某种无冲突HASH算法，将类名转换成为一个唯一整数。使用标准CRC32算法从类型名计算出一个整数作为类ID也许是个不错的想法[3]。

　　程序清单

　　实现结果

　　本文实现了如下几个宏来支持RTTI，它们的使用方法都可以在上面的代码中找到：
　　

性能测试

　　测试代码：

　　这里使用相同次数的DYNAMIC_CAST和dynamic_cast进行对比测试，在VC6.0下编译运行，使用默认的Release编译配置选项。为了避免编译器优化导致的不公平测试结果，我在循环中加入了无意义的计数操作。

　　运行结果：

　　这是上述条件下的测试输出，我们可以看到，本文实现的这个精简RTTI方案运行DYNAMIC_CAST的时间开销只有dynamic_cast的1/3。为了得到更全面的数据，还进行了DEBUG编译配置选项下的测试。

　　输出：

　　这种情况下DYNAMIC_CAST运行速度要比dynamic_cast慢一倍左右。如果在Release编译配置选项下将UObject::IsKindOf方法改成如下inline函数，我们将得到更让人兴奋的结果（DYNAMIC_CAST运行时间只有dynamic_cast的1/5）。

　　输出：

　　结论：

　　由本文的实践可以得出结论，自己动手编码实现RTTI是简单可行的。这样的实现可以在编译器优秀的代码优化中表现出比dynamic_cast更好的性能，而且没有带来过多的存储开销。本文的RTTI以性能为主要设计目标，在实现上一定程度上受到了MFC的影响。适于嵌入式环境。

第三章

链接指示符extern C
如果程序员希望调用其他程序设计语言尤其是C 写的函数，那么调用函数时必须
告诉编译器使用不同的要求，例如当这样的函数被调用时，函数名或参数排列的顺序可能
不同，无论是C++函数调用它还是用其他语言写的函数调用它
程序员用链接指示符linkage directive 告诉编译器该函数是用其他的程序设计语言
编写的，链接指示符有两种形式：既可以是单一语句single statement 形式。也可以是复
合语句compound statement 形式
// 单一语句形式的链接指示符
extern "C" void exit(int);
// 复合语句形式的链接指示符
extern "C" {
int printf( const char* ... );
int scanf( const char* ... );
}
// 复合语句形式的链接指示符
extern "C" {
#include <cmath>
}
链接指示符的第一种形式由关键字extern 后跟一个字符串常量以及一个普通的函数
声明构成，虽然函数是用另外一种语言编写的，但调用它仍然需要类型检查，例如编译器
会检查传递给函数exit()的实参的类型是否是int ，或者能够隐式地转换成int 型
多个函数声明可以用花括号包含在链接指示符复合语句中，这是链接指示符的第二种形
式，花招号被用作分割符表示链接指示符应用在哪些声明上，在其他意义上该花括号被忽
略，所以在花括号中声明的函数名对外是可见的就好像函数是在复合语句外声明的一样
例如在前面的例子中复合语句extern "C"表示函数printf()和scanf()是在C 语言中写的，
函数因此这个声明的意义就如同printf()和scanf()是在extern "C"复合语句外面声明的
一样，
当复合语句链接指示符的括号中含有#include 时在头文件中的函数声明都被假定是用
链接指示符的程序设计语言所写的在前面的例子中在头文件<cmath>中声明的函数都是C
函数
链接指示符不能出现在函数体中下列代码段将会导致编译错误
int main()
{
// 错误: 链接指示符不能出现在函数内
extern "C" double sqrt( double );
305 第七章函数
double getValue(); //ok
double result = sqrt ( getValue() );
//...
return 0;
}
如果把链接指示符移到函数体外程序编译将无错误
extern "C" double sqrt( double );
int main()
{
double getValue(); //ok
double result = sqrt ( getValue() );
//...
return 0;
}
但是把链接指示符放在头文件中更合适，在那里函数声明描述了函数的接口所属
如果我们希望C++函数能够为C 程序所用又该怎么办呢？我们也可以使用extern "C"
链接指示符来使C++函数为C 程序可用例如：
// 函数calc() 可以被C 程序调用
extern "C" double calc( double dparm ) { /* ... */ }
如果一个函数在同一文件中不只被声明一次，则链接指示符可以出现在每个声明中，它
也可以只出现在函数的第一次声明中在这种情况下第二个及以后的声明都接受第一个声
明中链接指示符指定的链接规则例如
// ---- myMath.h ----
extern "C" double calc( double );
// ---- myMath.C ----
// 在Math.h 中的calc() 的声明
#include "myMath.h"
// 定义了extern "C" calc() 函数
// calc() 可以从C 程序中被调用
double calc( double dparm ) { // ...
在本节中我们只看到为C 语言提供的链接指示extern "C"， extern "C"是惟一被
保证由所有C++实现都支持的每个编译器实现都可以为其环境下常用的语言提供其他链接
指示，例如：extern "Ada"可以用来声明是用Ada 语言写的函数，extern "FORTRAN"用来
声明是用FORTRAN 语言写的函数等等，因为其他的链接指示随着具体实现的不同而不同
所以建议读者查看编译器的用户指南以获得其他链接指示符的

第四章

Run-time type information (RTTI) is a mechanism that allows the type of an object to be determined during program execution.
RTTI was added to the C++ language because many vendors of class libraries were implementing this functionality themselves.
This caused incompatibilities between libraries.
Thus, it became obvious that support for run-time type information was needed at the language level.

For the sake of clarity, this discussion of RTTI is almost completely restricted to pointers. However, the concepts discussed also apply to references.

There are three main C++ language elements to run-time type information:

• The dynamic_cast operator.

Used for conversion of polymorphic types.

• The typeid operator.

Used for identifying the exact type of an object.

• The type_info class.

Used to hold the type information returned by the typeid operator.

Visual C++ Compiler Options

/GR (Enable Run-Time Type Information)

This option (/GR) adds code to check object types at run time.
When this option is specified, the compiler defines the _CPPRTTI preprocessor macro. The option is cleared (/GR–) by default.

To set this compiler option in the Visual Studio development environment
   1. Open the project‘s Property Pages dialog box. For details,
         see Setting Visual C++  Project Properties.
   2. Click the C/C++ folder.
   3. Click the Language property page.
   4. Modify the Enable Run-Time Type Info property.

典型的RTTI是通过在VTable中放一个额外的指针来实现的。这个指针指向一个描述该特定类型的
typeinfo结构（每个新类只产生一个typeinfo的实例），所以typeid()表达式的作用实际上很简单。
VPtr用来取typeinfo的指针，然后产生一个结果typeinfo结构的一个引用，然后调用库中的一个例程判
断源typeinfo是否与目标typeinfo相同或者是目标typeinfo的派生类。

MFC的RTTI主要是通过CRuntimeClass实现的。我们的类只需从CObject派生，并分别在头文件和实
现文件中声明DECLARE_DYNAMIC/IMPLEMENT_DYNAMIC或
DECLARE_DYNCREATE/IMPLEMENT_DYNCREATE或
DECLARE_SERIAL/IMPLEMENT_SERIAL 宏就可拥有RTTI。

CRuntimeClass is a structure and therefore does not have a base class.

CRuntimeClass is a structure you can use to obtain information about an object or its
base class at run time. The ability to determine the class of an object at run time is
useful when extra type checking of function arguments is needed, or when you must
write special-purpose code based on the class of an object.

Each class derived from CObject is associated with a CRuntimeClass structure that you can use to obtain information about an object or its base class at run time. Run-time
class information is not supported directly by the C++ language.

CRuntimeClass provides information on the related C++ object, such as a pointer to
the CRuntimeClass of the base class and the ASCII class name of the related class.
This structure also implements various functions that can be used to dynamically create
objects, specifying the type of object by using a familiar name, and determining if the
related class is derived from a specific class.

struct CRuntimeClass {
 LPCSTR m_lpszClassName;
 int m_nObjectSize;
 UINT m_wSchema CObject* (PASCAL* m_pfnCreateObject)( );
 CRuntimeClass* (PASCAL* m_pfnGetBaseClass)( );
 CRuntimeClass* m_pBaseClass;
 CObject* CreateObject( );
 BOOL IsDerivedFrom(const CRuntimeClass* pBaseClass) const;
 void Store(CArchive& ar) const;
 static CRuntimeClass* PASCAL Load( Carchive& ar, UINT* pwSchemaNum);
 CRuntimeClass* m_pNextClass;
 };

类比：
   1. CObject::GetRuntimeClass() <==> typeid(object)
   2. RUNTIME_CLASS(classname) <==> typeid(classname)
   3. CObject::IsKindOf(RUNTIME_CLASS(classname)) 
         <==>
       typeid(object) == typeid (classname)
   4. CRuntimeClass::IsDeriveFrom(RUNTIME_CLALL(classname))
         <==>
       dynamic_cast<classname*>(ptr) != NULL
   
在编写MFC程序的时候，最好不要用c++ RTTI以免增加开销。因为他们的实现各自独立而且MFC的
CRuntime实现的功能是RTTI的超集，因为CRuntime还支持动态创建，因而也支持序列化。

C++中的RTTI(转)