MFC六大核心机制之二：运行时类型识别（RTTI）
上一節講的是MFC六大核心機制之一：MFC程序的初始化，本節繼續講解MFC六大核心機制之二：運行時類型識別（RTTI）。
???????typeid運算子
?????? 運行時類型識別（RTTI）即是程序執行過程中知道某個對象屬于某個類，我們平時用C++編程接觸的RTTI一般是編譯器的RTTI，即是在新版本的VC++編譯器里面選用“使能RTTI”，然后載入typeinfo.h文件，就可以使用一個叫typeid()的運算子，它的地位與在C++編程中的sizeof()運算子類似的地方（包含一個頭文件，然后就有一個熟悉好用的函數）。typdid()關鍵的地方是可以接受兩個類型的參數：一個是類名稱，一個是對象指針。所以我們判別一個對象是否屬于某個類就可以象下面那樣：
C++代碼?????? 像上面所說的那樣，一個typeid()運算子就可以輕松地識別一個對象是否屬于某一個類，但MFC并不是用typeid()的運算子來進行動態類型識別，而是用一大堆令人費解的宏。很多學員在這里很疑惑，好象MFC在大部分地方都是故作神秘。使們大家編程時很迷惘，只知道在這里加入一組宏，又在那兒加入一個映射，而不知道我們為什么要加入這些東東。
?????? 其實，早期的MFC并沒有typeid()運算子，所以只能沿用一個老辦法。我們甚至可以想象一下，如果MFC早期就有template（模板）的概念，可能更容易解決RTTI問題。
?????? 所以，我們要回到“古老”的年代，想象一下，要完成RTTI要做些什么事情。就好像我們在一個新型（新型到我們還不認識）電器公司里面，我們要識別哪個是電飯鍋，哪個是電磁爐等等，我們要查看登記的各電器一系列的信息，我們才可以比較、鑒別，那個東西是什么！
???????CRuntimeClass鏈表的設計
?????? 要登記一系列的消息并不是一件簡單的事情，大家可能首先想到用數組登記對象。但如果用數組，我們要定義多大的數組才好呢，大了浪費空間，小了更加不行。所以我們要用另一種數據結構——鏈表。因為鏈表理論上可大可小，可以無限擴展。
?????? 鏈表是一種常用的數據結構，簡單地說，它是在一個對象里面保存了指向下一個同類型對象的指針。我們大體可以這樣設計我們的類：
C++代碼?????? 鏈表還應該有一個表頭和一個表尾，這樣我們在查鏈表中各對象元素的信息的時候才知道從哪里查起，到哪兒結束。我們還要注明本身是由哪能個類派生。所以我們的鏈表類要這樣設計：
C++代碼?????? 有了CRuntimeClass結構后，我們就可以定義鏈表了：
C++代碼?????? 至于pFirstClass（表頭），大家可能有點想不通，它到什么地方去了。因為我們這里并不想把classCObject作為鏈表表頭，我們還要在前面插入很多的CRuntimeClass對象，并且因為pFirstClass為static指針，即是說它不是屬于某個對象，所以我們在用它之前要先初始化：CRuntimeClass* CRuntimeClass：：pFirstClass=NULL;。
???????現在我們可以在前面插入一個CRuntimeClass對象，插入之前我得重要申明一下：如果單純為了運行時類型識別，我們未必用到m_pNextClass指針（更多是在運行時創建時用），我們關心的是類本身和它的基類。這樣，查找一個對象是否屬于一個類時，主要關心的是類本身及它的基類。
C++代碼?????? 好了，上面只是僅僅為一個指針m_pBaseClass賦值（MFC中真正CRuntimeClass有多個成員變量和方法），就連接成了鏈表。假設我們現在已全部構造完成自己需要的CRuntimeClass對象，那么，這時候應該定義表頭。即要用pFirstClass指針指向我們最后構造的CRuntimeClass對象——classCView。
C++代碼?????? 現在鏈表有了，表頭表尾都完善了，問題又出現了，我們應該怎樣訪問每一個CRuntimeClass對象？要判斷一個對象屬于某類，我們要從表頭開始，一直向表尾查找到表尾，然后才能比較得出結果嗎。肯定不是這樣！
???????類中構造CRuntimeClass對象
?????? 大家可以這樣想一下，我們構造這個鏈表的目的，就是構造完之后，能夠按主觀地拿一個CRuntimeClass對象和鏈表中的元素作比較，看看其中一個對象是否屬于你指定的類。這樣，我們需要有一個函數，一個能返回自身類型名的函數GetRuntimeClass()。
?????? 上面簡單地說了一下鏈表的過程，但單純有這個鏈表是沒有任何意義。回到MFC中來，我們要實現的是在每個需要有RTTI能力的類中構造一個CRuntimeClass對象，比較一個類是否屬于某個CRuntimeClass對象的時候，實際上只是比較CRuntimeClass對象。
?????? 如何在各個類之中插入CRuntimeClass對象，并且指定CRuntimeClass對象的內容及CRuntimeClass對象的鏈接，這里起碼有十行的代碼才能完成。在每個需要有RTTI能力的類設計中都要重復那十多行代碼是一件乏味的事情，也容易出錯，所以MFC用了兩個宏代替這些工作，即DECLARE_DYNAMIC(類名)和IMPLEMENT_DYNAMIC(類名，基類名)。從這兩個宏我們可以看出在MFC名類中的CRuntimeClass對象構造連接只有類名及基類名的不同！
???????到此，可能會有朋友問：為什么要用兩個宏，用一個宏不可以代換CRuntimeClass對象構造連接嗎？個人認為肯定可以，因為宏只是文字代換的游戲而已。但我們在編程之中，頭文件與源文件是分開的，我們要在頭文件頭聲明變量及方法，在源文件里實具體實現。即是說我們要在頭文件中聲明：
C++代碼?????? 然后在源文件里實現：
C++代碼?????? 我們一眼可以看出MFC中的DECLARE_DYNAMIC(類名)宏應該這樣定義：
C++代碼?????? 其中##為連接符，可以讓我們傳入的類名前面加上class，否則跟原類同名，大家會知道產生什么后果。
?????? 有了上面的DECLARE_DYNAMIC(類名)宏之后，我們在頭文件里寫上一句
?????? DECLARE_DYNAMIC(XXX)
?????? 宏展開后就有了我們想要的：
?????? public:
???????????? static CRuntimeClass classXXX? //XXX為類名
???????????? virtual CRuntime* GetRuntimeClass() const;
?????? 對于IMPLEMENT_DYNAMIC(類名，基類名)，看來也不值得在這里代換文字了，大家知道它是知道回事，宏展開后為我們做了什么，再深究真是一點意義都沒有！
有了此鏈表之后，就像有了一張存放各類型的網，我們可以輕而易舉地RTTI。
???????IsKindOf函數
?????? CObject有一個函數BOOL IsKindOf(const CRuntimeClass* pClass) const;，被它以下所有派生類繼承。
???????此函數實現如下：
C++代碼?????? 說到這里，運行時類型識別（RTTI）算是完成了。
總結
以上是生活随笔為你收集整理的MFC六大核心机制之二：运行时类型识别（RTTI）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： MFC六大核心机制之一：MFC程序的初始
- 下一篇： MFC六大核心机制之三：动态创建