追根究底，MFC六大關鍵技術之剖析（二）
二、運行時類型識別（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）即是程序執行過程中知道某個對象屬於某個類，我們平時用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）算是完成了。寫這篇文章的時候，我一直重感冒。我曾一度在想，究竟寫這東西是爲了什麼。因爲如果我把這些時間用在別的地方（甚至幫別人打打字），應該有數百元的報酬。
是什麼讓“嗜財如命”的我繼續寫下去？我想，無非是想交幾個計算機的朋友而已。計算機是大家公認高科技的東西，但學習它的朋友大多隻能默默無聞，外界的朋友也不知道怎麼去認識你。程序員更不是“潮流”的東西，更加得不到別人的認可。
有一件個人認爲很典型的事情，有一天，我跟一個朋友到一個單位裏面。裏面有一個女打字員。朋友看着她熟練的指法，心悅誠服地說：“她的電腦水平比你的又高了一個很高的層次！”，那個女的打字高手亦自豪地說：“我靠電腦爲生，電腦水平肯定比你（指筆者）的好一點！換着是你，如果以電腦爲生，我也不敢說好過你！”。雖然我想聲明我是計算機專業的，但我知道沒有理解，所以我只得客氣地點頭。
選擇電腦“潮流”的東西實際是選擇了平凡，而選擇做程序員就是選擇了孤獨！幸好我不是一個專門的程序員，但即使如此，我願意做你們的朋友，因爲我愛你們
