MFC六大關鍵技術

本文轉自http://blog.csdn.net/netanimals/article/details/6595467

我并不認為MFC減輕了程式員們的負擔，MFC出現的目的雖然似乎是為了讓程式員不用懂得太多就可以進行視窗程式設計，但本人在MFC裡徘徊了很久很久（因為那時沒有書本詳細介紹MFC的原理），毫無收獲。可能朋友們會說，怎麼一定要了解MFC的具體呢，“黑箱”作業不行嗎？這不是微軟的初衷嗎？

　　不行！！！如果這樣，我甯願永遠不選擇MFC！在學電腦之前，本人學習的東西大都與藝術不無關系，國小時參加過全國書畫比賽獲銀獎。兒時的愛好就是在一張紙上随心所欲地畫畫！MFC“黑箱”就象一幅碩大的抽象畫（抽象到你不能了解），它用鉛筆勾畫好線條，然後請你填顔色。 

　　我們怎麼能忍受“黑箱”作業？我們選擇C++，就是因為它夠自由，夠藝術，我們可以在此放飛幻想。是以，我們要攻克MFC。

　　偉大孫老師在剖析MFC的時候雖然盡心盡力，但可能由于篇幅所限，說得并不大清楚（我相信許多學員都有這方面的感受）。在此，我突發奇想，想與大家一同分享一下著名的MFC六大關鍵技術。

　　從什麼地方開始講起好呢？我覺得回到最初摸索MFC的時候，從基本談起最好。

　　因為我知道，一個走過來程式員，總是忘記了當初自己是怎麼走過來的，忘記了一個學員最想知道的是什麼。一個小小的問題（一兩句話就可以解釋的），足學以令手無寸鐵的學員頭大半個月，是以，我努力回憶當初是怎麼讓自己豁然開朗的。

　　轉入正題，MFC的六大關鍵技術包括：

　　·MFC程式的初始化過程

　　·運作時類型識别（RTTI）

　　·動态建立

　　·永久儲存

　　·消息映射

　　·消息傳遞

　　

　　MFC程式的初始化過程

　　1、設計一個簡單完整MFC程式，産生一個視窗。當然這不能讓AppWizard自動為我們生成。我們可以在Win32 Application工程下面那樣寫：

#include ＜afxwin.h＞ class MyApp : public CWinApp { 　public: 　　BOOL InitInstance() //②程式入點 　　{ 　　　CFrameWnd *Frame=new CFrameWnd();//構造架構 　　　m_pMainWnd=Frame; //将m_pMainWnd設定為Frame; 　　　Frame-＞Create(NULL,"最簡單的視窗");//建立架構 　　　Frame-＞ShowWindow(SW_SHOW); //顯示架構 　　　return true; //傳回 　　} }; MyApp theApp; //①建立應用程式。

　　設定連結MFC庫，運作，即可看見一個視窗。

　　從上面，大家可以看到建立一個MFC視窗很容易，隻用兩步：一是從CWinApp派生一個應用程式類（這裡是MyApp），,然後建立應用程式對象（theApp），就可以産生一個自己需要的視窗(即需要什麼樣就在InitInstance()裡建立就行了)。

　　整個程式，就改寫一個InitInstance()函數，建立那麼一個對象（theApp）,就是一個完整的視窗程式。這就是“黑箱”作業的魅力！！！！

　　在我們正想為微軟鼓掌的時候，我們突然覺得心裡空蕩蕩的，我們想知道微軟幫我們做了什麼事情，而我們想編自己的程式時又需要做什麼事情，那怕在上面幾行的程式裡面，我們還有不清楚的地方，比如，幹嘛有一個m_pMainWnd指針變量，它從哪裡來，又要到哪裡去呢？想一想在DOS下程式設計是多麼美妙的一件事呵，我們需要什麼變量，就聲明什麼變量，需要什麼樣的函數，就編寫什麼樣的函數，或者引用函數庫……但是現在我們怎麼辦！！！

　　我們可以逆向思維一下，MFC要達到這種效果，它是怎麼做的呢？首先我們要弄明白，VC不是一種語言，它就象我們學c語言的時候的一個類似記事本的編輯器（請原諒我的不貼切的比喻），是以，在VC裡面我們用的是C++語言程式設計，C++才是根本（初學者總是以為VC是一門什麼新的什麼語言，一門比C++先進很多的複雜語言，汗）。說了那麼多，我想用一句簡單的話概括“MFC‘黑箱’就是幫助我們插入了‘C++代碼’的東西”。

　　既然MFC黑箱幫我們插入了代碼，那麼大家想想它會幫我們插入什麼樣的代碼呢？他會幫我們插入求解一進制二次方程的代碼嗎？當然不會，是以它插入的實際上是每次編寫視窗程式必須的，通用的代碼。

　　再往下想，什麼才是通用的呢？我們每次視窗程式設計都要寫WinMain()函數，都要有注冊視窗，産生視窗，消息循環，回調函數……即然每次都要的東西，就讓它們從我們眼前消失，讓MFC幫忙寫入！

　　要知道MFC初始化過程，大家當然可以跟蹤執行程式。孫老師的第三課跟蹤了很長一段時間，我相信大家都有點暈頭轉向。本人覺得那怕你了解了MFC代碼，也很容易讓人找不着北，我們完全不懂的時候，在成千上萬行程式的迷宮中如何能找到出口？

　　我們要換一種方法，不如就來重新編寫個MFC庫吧，嘩！大家不要笑，小心你的大牙，我不是瘋子（雖然瘋子也說自己不瘋）。我們要寫的就是最簡單的MFC類庫，就是把MFC宏觀上的，理論上的東西寫出來。我們要用最簡化的代碼，簡化到剛好能運作。

　　既然，我們這一節寫的是MFC程式的初始化過程，上面我們還有了一個可執行的MFC程式。程式中隻是用了兩個MFC類，一個是CWinApp,另一個是CFrameWnd。當然，還有很多同樣重要MFC類如視圖類，文檔類等等。但在上面的程式可以不用到，是以暫時省去了它（總之是為了簡單）。

　　好，現在開始寫MFC類庫吧……唉，面前又有一個大難題，就是讓大家背一下MFC層次結構圖。天，那張魚網怎麼記得住，但既然我們要了解他，總得知道它是從那裡派生出來的吧。

　　考慮到大家都很辛苦，那我們看一下上面兩個類的父子關系(箭頭代表派生)：

CObject-＞CCmdTarget-＞CWinThread-＞CWinApp-＞自己的重寫了InitInstance()的應用程式類。 CObject（同上）-＞CCmdTarget（同上）-＞CWnd-＞CFrameWnd

　　看到層次關系圖之後，終于可以開始寫MFC類庫了。按照上面層次結構，我們可以寫以下六個類（為了直覺，省去了構造函數和析構函數）。

/ class CObiect{};//MFC類的基類。 class CCmdTarget : public CObject{}; ------------------------------------------------ class CWinThread : public CCmdTarget{}; class CWinApp : public CWinThread{}; ------------------------------------------------ class CWnd : public CCmdTarget{}; class CFrameWnd : public CWnd{}; /

　　大家再想一下，在上面的類裡面，應該有什麼？大家馬上會想到，CWinApp類或者它的基類CCmdTarget裡面應該有一個虛函數virtual BOOL InitInstance(),是的，因為那裡是程式的入口點，初始化程式的地方，那自然少不了的。可能有些朋友會說，反正InitInstance()在派生類中一定要重載，我不在CCmdTarget或CWinApp類裡定義，留待CWinApp的派生類去增加這個函數可不可以。扯到這個問題可能有點越說越遠，但我想信C++的朋友對虛函數應該是沒有太多的問題的。總的來說，作為程式員如果清楚知道基類的某個函數要被派生類用到，那定義為虛函數要友善很多。也有很多朋友問，C++為什麼不自動把基類的所有函數定義為虛函數呢，這樣可以省了很多麻煩，這樣所有函數都遵照派生類有定義的函數就調用派生類的，沒定義的就調用基類的，不用寫virtual的麻煩多好！其實，很多面向對象的語言都這樣做了。但定義一個虛函數要生成一個虛函數表，要占用系統空間，虛函數越多，表就越大，有時得不償失！這裡哆嗦幾句，是因為往後要說明的消息映射中大家更加會體驗到這一點，好了，就此打往。

　　上面我們自己解決了一個問題，就是在CCmdTarge寫一個virtual BOOL InitInstance()。

　　大家再下想，我們還要我們MFC“隐藏”更多的東西：WinMain()函數，設計視窗類，視窗注冊，消息循環，回調函數……我們馬上想到封裝想封裝他們。大家似乎隐約地感覺到封裝WinMain()不容易, 覺得WinMain()是一個特殊的函數，許多時候它代表了一個程式的起始和終結。是以在以前寫程式的時候，我們寫程式習慣從WinMain()的左大括寫起，到右大括弧傳回、結束程式。 

　　我們換一個角度去想，有什麼東西可以拿到WinMain()外面去做，許多初學者們，總覺得WinMain()函數天大的函數，什麼函數都好象要在它裡面才能真正運作。其實這樣了解很片面，甚至錯誤。我們可以寫一個這樣的C++程式：

#include ＜iostream.h＞ class test{ 　public: 　　test(){cout＜＜"請改變你對main()函數的看法！"＜＜endl;} }; test test1; void main(){}

　　在上面的程式裡，入口的main()函數表面上什麼也不做，但程式執行了（注：實際入口函數做了一些我們可以不了解的事情），并輸出了一句話（注：全局對象比main()首先運作）。現在大家可以知道我們的WinMain()函數可以什麼都不做，程式依然可以運作，但沒有這個入口函數程式會報錯。

　　那麼WinMain()函數會放哪個類上面呢，請看下面程式：

#include ＜afxwin.h＞ class MyApp : public CWinApp { 　public: 　　BOOL InitInstance() //②程式入點 　　{ 　　　AfxMessageBox("程式依然可以運作！"); 　　　return true; 　　} }; MyApp theApp; //①建立應用程式。

　　大家可以看到，我并沒有構造架構，而程式卻可以運作了——彈出一個對話框（如果沒有WinMain()函數程式會報錯）。上面我這樣寫還是為了直覺起見，其實我們隻要寫兩行程式：

#include ＜afxwin.h＞ CWinApp theApp;  //整個程式隻構造一個CWinApp類對象，任可事情，程式就可以運作！

　　是以說，隻要我們構造了CWinApp對象，就可以執行WinMain()函數。我們馬上相信WinMain()函數是在CWinApp類或它的基類中，而不是在其他類中。其實這種看法是錯誤的，我們知道編寫C++程式的時候，不可能讓你在一個類中包含入口函數，WinMain()是由系統調用，跟我們的平時程式自身調用的函數有着本質的差別。我們可以暫時簡單想象成，當CWinApp對象構造完的時候，WinMain()跟着執行。

　　現在大家明白了，大部分的“通用代碼（我們想封裝隐藏的東西）”都可以放到CWinApp類中，那麼它又是怎樣運作起來的呢？為什麼構造了CWinApp類對象就“自動”執行那麼多東西。

　　大家再仔細想一下，CWinApp類對象構造之後，它會“自動”執行自己的構造函數。那麼我們可以把想要“自動”執行的代碼放到CWinApp類的構造函數中。

　　那麼CWinApp類可能打算這樣設計（先不計較正确與否）：

class CWinApp : public CWinThead{ 　public: 　　virtual BOOL InitInstance(); //解釋過的程式的入點 　　CWinApp ::CWinApp(){ //構造函數 　　　 　　　WinMain(); //這個是大家一眼看出的錯誤 　　　Create(); //設計、建立、更新顯示視窗 　　　Run(); //消息循環 　　　// 　　} };

　　寫完後，大家又馬上感覺到似乎不對，WinMain()函數在這裡好象真的一點用處都沒有，并且能這樣被調用嗎（請允許我把手按在聖經上聲明一下：WinMain()不是普通的函數，它要肩負着初始化應用程式，包括全局變量的初始化，是由系統而不是程式本身調用的，WinMain()傳回之後，程式就結束了，程序撤消）。再看Create()函數，它能确定設計什麼樣的視窗，建立什麼樣的視窗嗎？如果能在CWinApp的構造函數裡确定的話，我們以後設計MFC程式時視窗就一個樣，變得寫程式變有必要。再看Run()函數，它能在WinMain()函數外面運作嗎？

　　回過頭來，我們可以讓WinMain()函數一條語句都不包含嗎？不可以，我們看一下WinMain() 函數的四個參數：

WinMain(HINSTANCE, HINSTANCE, LPSTR, int)

　　其中第一個參數指向一個執行個體句柄，我們在設計WNDCLASS的時候一定要指定執行個體句柄。我們視窗程式設計，肯定要設計視窗類。是以，WinMain()再簡單也要這樣寫：

int WinMain(HINSTANCE hinst, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { hInstance=hinst }

　　既然執行個體句柄要等到程式開始執行才能知道，那麼我們用于建立視窗的Create()函數也要在WinMain（）内部才能執行[因為如果等到WinMain（）執行完畢後，程式結束，程序撤消，當然Create()也不可能建立視窗]

　　那麼Run()(消息循環)放在那裡執行好呢？衆所周知，消息循環就是相同的那麼幾句代碼，但我們也不要企圖把它放在WinMain（）函數之外執行。

　　是以我們在WinMain（）函數裡面，我們程式要象以下這樣寫

WinMain（……） { 　……視窗類對象執行建立視窗函數…… 　……程式類對象執行消息循環函數…… }

　　對于WinMain（）的問題，得總結一下，我們封裝的時候是不可以把它封裝到CWinApp類裡面，但由于WinMain（）的不變性（或者說有規律可循），MFC完全有能力在我們構造CWinApp類對象的時候，幫我們完成那幾行代碼。

　　轉了一個大圈，我們仿佛又回到了SDK程式設計的開始。但現在我們現在能清楚地知道，表面上MFC與SDK程式設計截然不同，但實質上MFC隻是用類的形式封裝了SDK函數，封裝之後，我們在WinMain（）函數中隻需要幾行代碼，就可以完成一個視窗程式。我們也由此知道了應如何去封裝應用程式類（CWinApp）和主架構視窗類（CFrameWnd）。下面把上開始設計這兩個類。

　　為了簡單起見，我們忽略這兩個類的基類和派生類的編寫，可能大家會認為這是一種很不負責任的做法，但本人覺得這既可減輕負擔，又免了大家在各類之間穿來穿去，更好了解一些（我們在關鍵的地方作注明）。還有，我把全部代碼寫在同一個檔案中，讓大家看起來不用那麼吃力，但這是最不提倡的寫代碼方法，大家不要學哦！

#include ＜windows.h＞ HINSTANCE hInstance; class CFrameWnd  { 　HWND hwnd; 　public: 　　CFrameWnd(); //也可以在這裡調用Create() 　　virtual ~CFrameWnd(); 　　int Create(); //類就留意這一個函數就行了！ 　　BOOL ShowWnd(); }; class CWinApp1  { 　public: 　　CFrameWnd* m_pMainWnd;//在真正的MFC裡面 　　//它是CWnd指針，但這裡由于不寫CWnd類 　　//隻要把它寫成CFrameWnd指針 　　CWinApp1* m_pCurrentWinApp;//指向應用程式對象本身 　　CWinApp1(); 　　virtual ~CWinApp1(); 　　virtual BOOL InitInstance();//MFC原本是必須重載的函數，最重要的函數！！！！ 　　virtual BOOL Run();//消息循環 }; CFrameWnd::CFrameWnd(){} CFrameWnd::~CFrameWnd(){} int CFrameWnd::Create() //封裝建立視窗代碼  { 　WNDCLASS wndcls; 　wndcls.style=0; 　wndcls.cbClsExtra=0; 　wndcls.cbWndExtra=0; 　wndcls.hbrBackground=(HBRUSH)GetStockObject(WHITE_BRUSH); 　wndcls.hCursor=LoadCursor(NULL,IDC_CROSS); 　wndcls.hIcon=LoadIcon(NULL,IDC_ARROW); 　wndcls.hInstance=hInstance; 　wndcls.lpfnWndProc=DefWindowProc;//預設視窗過程函數。 　//大家可以想象成MFC通用的視窗過程。 　wndcls.lpszClassName="視窗類名"; 　wndcls.lpszMenuName=NULL; 　RegisterClass(&wndcls); 　hwnd=CreateWindow("視窗類名","視窗執行個體标題名",WS_OVERLAPPEDWINDOW,0,0,600,400,NULL,NULL,hInstance,NULL); 　return 0; } BOOL CFrameWnd::ShowWnd()//顯示更新視窗 { 　ShowWindow(hwnd,SW_SHOWNORMAL); 　UpdateWindow(hwnd); 　return 0; } / CWinApp1::CWinApp1() { 　m_pCurrentWinApp=this; } CWinApp1::~CWinApp1(){} //以下為InitInstance()函數，MFC中要為CWinApp的派生類改寫， //這裡為了友善了解，把它放在CWinApp類裡面完成！ //你隻要記住真正的MFC在派生類改寫此函數就行了。 BOOL CWinApp1::InitInstance() { 　m_pMainWnd=new CFrameWnd; 　m_pMainWnd-＞Create(); 　m_pMainWnd-＞ShowWnd(); 　return 0; } BOOL CWinApp1::Run()//封裝消息循環 { 　MSG msg; 　while(GetMessage(&msg,NULL,0,0)) 　{ 　　TranslateMessage(&msg); 　　DispatchMessage(&msg); 　} 　return 0; } //封裝消息循環 CWinApp1 theApp; //應用程式對象（全局） int WINAPI WinMain( HINSTANCE hinst, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { 　hInstance=hinst; 　CWinApp1* pApp=theApp.m_pCurrentWinApp; 　//真正的MFC要寫一個全局函數AfxGetApp，以擷取CWinApp指針。 　pApp-＞InitInstance(); 　pApp-＞Run(); 　return 0; }

　　代碼那麼長，實際上隻是寫了三個函數，一是CFrameWnd類的Create(),第二個是CWinApp類的InitInstance()和Run()。在此特别要說明的是InitInstance()，真正的MFC中，那是我們跟據自己構造視窗的需要，自己改寫這個函數。

　　大家可以看到，封裝了上面兩個類以後，在入口函數WinMain中就寫幾行代碼，就可以産生一個視窗程式。在MFC中，因為WinMain函數就是固定的那麼幾行代碼，是以MFC絕對可以幫我們自動完成（MFC的特長就是幫我們完成有規律的代碼），是以我們創造MFC應用程式的時候，看不到WinMain函數。

　　寫到這裡，MFC六大關鍵技術之一：MFC程式的初始化過程（模拟），就差不多寫完了。回頭看一下，居然寫了八千多字，原本以為寫完六大關鍵技術也不用寫那麼多字，現在還覺得慶幸的是不把文檔、視類牽連進去，否則更不知寫到何時。

　　還有五大關鍵技術沒有寫，我還應該寫下去嗎？上面寫了八千多字，都是我一個字一個字地敲進去，每個例子都是自己生硬地想出來。用了十多個小時，換來的可能更多是論壇中朋友們的漫罵，譏諷！

　　但我覺得還是值得的，我一向認為VC沒有敵人，隻有朋友，放眼周圍，發覺學VC的朋友越來越少，也沒有發現多少招收VC程式員的地方。記得讀大學的時候，我遇到一位搞美術的師兄，本來同行如敵國（我曾經搞過美術）。師兄美術功底很好，但他從來沒有在學校獲過美術一等獎，原因評獎的不懂得欣賞他的作品。我的出現，他深刻地體會到了：多一個朋友，會少一分孤獨！有時覺得學習VC的朋友是英雄（但我不是英雄，因為我學VC多年來無甚突破），是值得尊敬的人物，大家交流一下，糾正一下自己的錯誤，真是一種福份……

二、運作時類型識别（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）算是完成了。寫這篇文章的時候，我一直重感冒。我曾一度在想，究竟寫這東西是為了什麼。因為如果我把這些時間用在别的地方（甚至幫别人打打字），應該有數百元的報酬。

是什麼讓“嗜财如命”的我繼續寫下去？我想，無非是想交幾個計算機的朋友而已。計算機是大家公認高科技的東西，但學習它的朋友大多隻能默默無聞，外界的朋友也不知道怎麼去認識你。程式員更不是“潮流”的東西，更加得不到别人的認可。

有一件個人認為很典型的事情，有一天，我跟一個朋友到一個機關裡面。裡面有一個女打字員。朋友看着她熟練的指法，心悅誠服地說：“她的電腦水準比你的又高了一個很高的層次！”，那個女的打字高手亦自豪地說：“我靠電腦為生，電腦水準肯定比你（指筆者）的好一點！換着是你，如果以電腦為生，我也不敢說好過你！”。雖然我想聲明我是計算機專業的，但我知道沒有了解，是以我隻得客氣地點頭。

選擇電腦“潮流”的東西實際是選擇了平凡，而選擇做程式員就是選擇了孤獨！幸好我不是一個專門的程式員，但即使如此，我願意做你們的朋友，因為我愛你們！

三、動态建立

 動态建立就是運作時建立指定類的對象，在MFC中大量使用。如架構視窗對象、視對象，還有文檔對象都需要由文檔模闆類對象來動态的建立。我覺得這是每個MFC的學習者很希望了解的問題。

初次接觸MFC的時候，很容易有這樣的迷惘。MFC的幾大類不用我們設計也就罷了，但最疑惑的是不用我們執行個體化對象。本來最直覺的了解就是，我們需要架構的時候，親手寫上CFrameWnd myFrame；需要視的時候，親自打上CView myView;……

 但MFC不給我們這個機會，緻使我們錯覺視窗沒有執行個體化就彈出來了！就象畫了張電視機的電路圖就可以看電視一樣令人難以置信。但大夥想了一下，可能會一拍腦門，認為簡單不過：MFC自動幫我們完成CView myView之流的代碼不就行了麼！！！其實不然，寫MFC程式的時候，我們幾乎要對每個大類進行派生改寫。換句話說，MFC并不知道我們打算怎樣去改寫這些類，當然也不打算全部為我們“靜态”建立這些類了。即使靜态了建立這些類也沒有用，因為我們從來也不會直接利用這些類的執行個體幹什麼事情。我們隻知道，想做什麼事情就往各大類裡塞，不管什麼變量、方法照塞，塞完之後，我們似乎并未執行個體化對象，程式就可以運作！

要做到把自己的類交給MFC，MFC就用同一樣的方法，把不同的類一一準确建立，我們要做些什麼事情呢？同樣地，我們要建立連結清單，記錄各類的關鍵資訊，在動态建立的時候找出這些資訊，就象上一節RTTI那樣！我們可以設計一個類：

struct CRuntimeClass{

 LPCSTR m_lpszClassName; //類名指針

 CObject* (PASCAL *m_pfnCreateObject)(); //建立對象的函數的指針

 CRuntimeClass* m_pBaseClass; //講RTTI時介紹過

 CRuntimeClass* m_pNextClass; //指向連結清單的下一個元素(許多朋友說上一節講RTTI時并沒有用到這個指針，我原本以為這樣更好了解一些，因為沒有這個指針，這個連結清單是無法連起來，而m_pBaseClass僅僅是向基類走，在MFC的樹型層次結構中m_pBaseClass是不能周遊的)

 CObject* CreateObject(); //建立對象

 static CRuntimeClass* PASCAL Load(); //周遊整個類型連結清單，傳回符合動态建立的對象。

static CRuntimeClass* pFirstClass; //類型連結清單的頭指針

};

一下子往結構裡面塞了那麼多的東西，大家可以覺得有點頭暈。至于CObject* (PASCAL *m_pfnCreateObject)();，這定義函數指針的方法，大家可能有點陌生。函數指針在C++書籍裡一般被定為選學章節，但MFC還是經常用到此類的函數，比如我們所熟悉的回調函數。簡單地說m_pfnCreateObject即是儲存了一個函數的位址，它将會建立一個對象。即是說，以後，m_pfnCreateObject指向不同的函數，我們就會建立不同類型的對象。

有函數指針，我們要實作一個與原定義參數及傳回值都相同一個函數，在MFC中定義為：

static CObject* PASCAL CreateObject(){return new XXX};//XXX為類名。類名不同，我們就建立不同的對象。

由此，我們可以如下構造CRuntimeClass到連結清單：

CRuntimeClass classXXX={

類名，

……，

XXX::CreateObject()， //m_pfnCreateObject指向的函數

RUNTIME_CLASS(基類名) // RUNTIME_CLASS宏可以傳回CRuntimeClass對象指針。

NULL //m_pNextClass暫時為空，最後會我們再設法讓它指向舊連結清單表頭。

};

這樣，我們用函數指針m_pfnCreateObject（指向CreateObject函數)，就随時可new新對象了。并且大家留意到，我們在設計CRuntimeClass類對時候，隻有類名（和基類名）的不同（我們用XXX代替的地方），其它的地方一樣，這正是我們想要的，因為我們動态建立也象RTTI那樣用到兩個宏，隻要傳入類名和基類作宏參數，就可以滿足條件。

即是說，我們類說明中使用DECLARE_DYNCREATE（CLASSNMAE）宏和在類的實作檔案中使用IMPLEMENT_DYNCREATE（CLASSNAME，BASECLASS）宏來為我們加傳入連結表，至于這兩個宏怎麼為我們建立一個連結清單，我們自己可以玩玩文字代換的遊戲，在此不一一累贅。但要說明的一點就是：動态建立宏xxx_DYNCREATE包含了RTTI宏，即是說， xxx_DYNCREATE是xxx_DYNAMIC的“增強版”。

到此，我們有必要了解一下上節課沒有明講的m_pNextClass指針。因為MFC層次結構是樹狀的，并不是直線的。如果我們隻有一個m_pBaseClass指針，它隻會沿着基類上去，會漏掉其它分支。在動态建立時，必需要檢查整個連結清單，看有多少個要動态建立的對象，即是說要從表頭（pFirstClass）開始一直周遊到表尾（m_pNextClass=NULL），不能漏掉一個CRuntimeClass對象。

是以每當有一個新的連結清單元素要加傳入連結表的時候，我們要做的就是使新的連結清單元素成為表頭，并且m_pNextClass指向原來連結清單的表頭，即像下面那樣（當然，這些不需要我們操心，是RTTI宏幫助我們完成的）：

pNewClass->m_pNextClass=CRuntimeClass::pFirstClass;//新元素的m_pNextClass指針指向想加入的連結清單的表頭。

 CRuntimeClass::pFirstClass=pNewClass;//連結清單的頭指針指向剛插入的新元素。

好了，有了上面的連結清單，我們就可以分析動态建立了。

有一了張有類名，函數指針，動态建立函數的連結清單，我們就可以知道應該按什麼步驟去動态建立了：1、獲得一要動态建立的類的類名（假設為A）。2、将A跟連結清單裡面每個元素的m_lpszClassName指向的類名作比較。3、若找到跟A相同的類名就傳回A所屬的CRuntimeClass元素的指針。4、判斷m_pfnCreateObject是否有指向建立函數，有則建立對象，并傳回該對象。代碼示範如下（以下兩個函數都是CRuntimeClass類函數）：

///以下為根據類名從表頭向表尾查找所屬的CRuntimeClass對象

CRuntimeClass* PASCAL CRuntimeClass::Load()

{

char szClassXXX[64];

CRuntimeClass* pClass;

cin>>szClassXXX; //假定這是我們希望動态建立的類名

for(pClass=pFirstClass;pClass!=NULL;pClass=pClass->m_pNextClass)

 {

 if(strcmp(szClassXXX,pClass->m_lpszClassName)==0)

 return pClass;

}

 return NULL

 }

///根據CRuntimeClass建立對象///

CObject* CRuntimeClass::CreateObject()

{

 if(m_pfnCreateObject==NULL) return NULL;

 CObject *pObject;

 pObject=(* m_pfnCreateObject)(); //函數指針調用

 return pObject;

}

有了上面兩個函數，我們在程式執行的時候調用，就可以動态建立對象了。

我們還可以更簡單地實作動态建立，大家注意到，就是在我們的程式類裡面有一個RUNTIME_CLASS(class_name)宏，這個宏在MFC裡定義為：

RUNTIME_CLASS(class_name) ((CRuntimeClass*)(&class_name::class##class_name))

 作用就是得到類的RunTime資訊，即傳回class_name所屬CRuntimeClass的對象。在我們的應用程式員類(CMyWinApp)的InitInstance()函數下面的CSingleDocTemplate函數中，有：

RUNTIME_CLASS(CMyDoc),

 RUNTIME_CLASS(CMainFrame), // main SDI frame window

 RUNTIME_CLASS(CMyView)

構造文檔模闆的時候就用這個宏得到文檔、架構和視的RunTime資訊。有了RunTime資訊，我們隻要一條語句就可以動态建立了，如：

classMyView->CreateObject(); //對象直接調用用CRuntimeClass本身的CreateObject()

現在，細心的朋友已經能清楚動态建立需要的步驟：

1、定義一個不帶參數的構造函數（預設構造函數）；因為我們是用CreateObject()動态建立，它隻有一條語句就是return new XXX，不帶任何參數。是以我們要有一個無參構造函數。

2、類說明中使用DECLARE_DYNCREATE（CLASSNMAE）宏；和在類的實作檔案中使用IMPLEMENT_DYNCREATE（CLASSNAME，BASECLASS）宏；這個宏完成構造CRuntimeClass對象，并加入到連結清單中。

3、使用時先通過宏RUNTIME_CLASS得到類的RunTime資訊，然後使用CRuntimeClass的成員函數CreateObject建立一個該類的執行個體。

4、CObject* pObject = pRuntimeClass->CreateObject();//完成動态建立。

 先用一句話來說明永久儲存的重要：弄懂它以後，你就越來越像個程式員了！ 

如果我們的程式不需要永久儲存，那幾乎可以肯定是一個小玩兒。那怕我們的記事本、畫圖等小程式，也需要儲存才有真正的意義。 

對于MFC的很多地方我不甚滿意，總覺得它喜歡拿一組低能而神秘的宏來故弄玄虛，但對于它的連續存儲（serialize）機制，卻是我十分鐘愛的地方。在此，可讓大家感受到面向對象的幸福。 

MFC的連續存儲（serialize）機制俗稱串行化。“在你的程式中盡管有着各種各樣的資料，serialize機制會象流水一樣按順序存儲到單一的檔案中，而又能按順序地取出，變成各種不同的對象資料。”不知我在說上面這一句話的時候，大家有什麼反應，可能很多朋友直覺是一件很簡單的事情，隻是說了一個“爽”字就沒有下文了。 

要實作象流水一樣存儲其實是一個很大的難題。試想，在我們的程式裡有各式各樣的對象資料。如畫圖程式中，裡面設計了點類，矩形類，圓形類等等，它們的繪圖方式及對資料的處理各不相同，用它們實作了成百上千的對象之後，如何存儲起來？不想由可，一想頭都大了：我們要在程式中設計函數store()，在我們單擊“檔案/儲存”時能把各對象往裡存儲。那麼這個store()函數要神通廣大，它能清楚地知道我們設計的是什麼樣的類，産生什麼樣的對象。大家可能并不覺得這是一件很困難的事情，程式有能力知道我們的類的樣子，對象也不過是一塊初始化了存儲區域罷了。就把一大堆對象“轉換”成磁盤檔案就行了。 

即使上面的存儲能成立，但當我們單擊“檔案/打開”時，程式當然不能預測使用者想打開哪個檔案，并且當打開檔案的時候，要根據你那一大堆垃圾資料new出數百個對象，還原為你原來存儲時的樣子，你又該怎麼做呢？ 

試想，要是我們有一個能容納各種不同對象的容器，這樣，使用者用我們的應用程式打開一個磁盤檔案時，就可以把檔案的内容讀進我們程式的容器中。把磁盤檔案讀進記憶體，然後識别它“是什麼對象”是一件很難的事情。首先，儲存過程不像電影的膠片，把景物直接映射進去，然後，看一下膠片就知道那是什麼内容。可能有朋友說它象錄像錄音帶，拿着錄像帶我們看不出裡面變化的磁場信号，但經過錄像機就能把它還原出來。 

其實不是這樣的，比如儲存一個矩形，程式并不是把矩形本身按點陣存儲到磁盤中，因為我們繪制矩形的整個過程隻不過是調用一個GDI函數罷了。它儲存隻是坐标值、線寬和某些标記等。程式面對“00 FF”這樣的東西，當然不知道它是一個圓或是一個字元！ 

拿剛才錄像帶的例子，我們之是以能最後放映出來，前提我們知道這對象是“錄像帶”，即确定了它是什麼類對象。如果我們事先隻知道它“裡面儲存有東西，但不知道它是什麼類型的東西”，這就導緻我們無法把它讀出來。拿錄像帶到錄音機去放，對錄音機來說，那完全是垃圾資料。即是說，要了解永久儲存，要對動态建立有深刻的認識。 

現在大家可以知道困難的根源了吧。我們在寫程式的時候，會不斷創造新的類，構造新的對象。這些對象，當然是舊的類對象（如MyDocument）從未見過的。那麼，我們如何才能使文檔對象可以儲存自己新對象呢，又能動态建立自己新的類對象呢？ 

許多朋友在這個時候想起了CObject這個類，也想到了虛函數的概念。于是以為自己“大緻了解”串行化的概念。他們設想：“我們設計的MyClass（我們想用于串行化的對象）全部從CObject類派生，CObject類對象當然是MyDocument能認識的。”這樣就實作了一個目的：本來MyDocument不能識别我們建立的MyClass對象，但它能識别CObject類對象。由于MyClass從CObject類派生，我産的新類對象“是一個CObject”，是以MyDocument能把我們的新對象當作CObiect對象讀出。或者根據書本上所說的：打開或儲存檔案的時候，MyDocument會調用Serialize（），MyDocument的Serialize（）函會呼叫我們建立類的Serialize函數[即是在MyDocument Serialize（）中調用：m_pObject->Serialize()，注意：在此m_pObject是CObject類指針，它可以指向我們設計的類對象]。最終結果是MyDocument的讀出和儲存變成了我們建立的類對象的讀出和儲存，這種認識是不明朗的。 

有意思還有，在網上我遇到幾位自以為懂了Serialize的朋友，居然不約而同的犯了一個很低級得讓人不可思議的錯誤。他們說：Serialize太簡單了！Serialize（）是一個虛函數，虛函數的作用就是“優先派生類的操作”。是以MyDocument不實作Serialize（）函數，留給我們自己的MyClass對象去調用Serialize（）……真是哭笑不得，我們建立的類MyClass并不是由MyDocument類派生，Serialize（）函數為虛在MyDocument和MyClass之間沒有任何意義。MyClass産生的MyObject對象僅僅是MyDocument的一個成員變量罷了。 

話說回來，由于MyClass從CObject派生，是以CObject類型指針能指向MyClass對象，并且能夠讓MyClass對象執行某些函數（特指重載的CObject虛函數），但前提必須在MyClass對象執行個體化了，即在記憶體中占領了一塊存儲區域之後。不過，我們的問題恰恰就是在應用程式随便打開一個檔案，面對的是它不認識的MyClass類，當然執行個體化不了對象。 

幸好我們在上一節課中懂得了動态建立。即想要從CObject派生的MyClass成為可以動态建立的對象隻要用到DECLARE_DYNAMIC/IMPLEMENT_DYNAMIC宏就可以了（注意：最終可以Serialize的對象僅僅用到了DECLARE_SERIAL/IMPLEMENT_SERIAL宏，這是因為DECLARE_SERIAL/IMPLEMENT_SERIAL包含了DECLARE_DYNAMIC/IMPLEMENT_DYNAMIC宏）。 

從解決上面的問題中，我們可以分步了解了： 

1、 Serialize的目的：讓MyDocument對象在執行打開/儲存操作時，能讀出（構造）和儲存它不認的MyClass類對象。 

2、 MyDocument對象在執行打開/儲存操作時會調用它本身的Serialize（）函數。但不要指望它會自動儲存和讀出我們的MyClass類對象。這個問題很容易解決，就直接在MyDocument:: Serialize（）{ 

// 在此函數調用MyClass類的Serialize（）就行了！即 

MyObject. Serialize（）; 

} 

3、 我們希望MyClass對象為可以動态建立的對象，是以要求在MyClass類中加上DECLARE_DYNAMIC/IMPLEMENT_DYNAMIC宏。 

但目前的Serialize機制還很抽象。我們僅僅知道了表面上的東西，實際又是如何的呢？下面作一個簡單深刻的詳解。 

先看一下我們文檔類的Serialize（） 

void CMyDoc::Serialize(CArchive& ar) 

{ 

if (ar.IsStoring()) 

{ 

// TODO: add storing code here 

} 

else 

{ 

// TODO: add loading code here 

} 

} 

目前這個子數什麼也沒做（沒有資料的讀出和寫入），CMyDoc類正等待着我們去改寫這個函數。現在假設CMyDoc有一個MFC可識别的成員變量m_MyVar,那麼函數就可改寫成如下形式： 

void CMyDoc::Serialize(CArchive& ar) 

{ 

if (ar.IsStoring()) //讀寫判斷 

{ 

ar<<m_MyVar; //寫 

} 

else 

{ 

ar>>m_MyVar; //讀 

} 

} 

許多網友問：自己寫的類（即MFC未包含的類）為什麼不行？我們在CMyDoc裡包含自寫類的頭檔案MyClass.h，這樣CMyDoc就認識MyDoc類對象了。這是一般常識性的錯誤，MyDoc類認識MyClass類對象與否并沒有用，關鍵是CArchive類，即對象ar不認識MyClass（當然你夢想重寫CArchive類當别論）。“>>”、“<<”都是CArchive重載的操作符。上面ar>>m_MyVar說白即是在執行一個以ar和m_MyVar 為參數的函數，類似于function(ar,m_MyVar)罷了。我們當然不能傳遞一個它不認識的參數類型，也是以不會執行function(ar,m_MyObject)了。 

[注：這裡我們可以用指針。讓MyClass從Cobject派生，一切又起了質的變化，假設我們定義了：MyClass *pMyClass = new MyClass;因為MyClass從CObject派生，根據虛函數原理，pMyClass也是一個CObject*，即pMyClass指針是CArchive類可認識的。是以執行上述function(ar, pMyClass)，即ar << pMyClass是沒有太多的問題（在保證了MyClass對象可以動态建立的前提下）。] 

回過頭來，如果想讓MyClass類對象能Serialize，就得讓MyClass從CObject派生，Serialize（）函數在CObject裡為虛，MyClass從CObject派生之後就可以根據自己的要求去改寫它，象上面改寫CMyDoc::Serialize（）方法一樣。這樣MyClass就得到了屬于MyClass自己特有的Serialize（）函數。 

現在，程式就可以這樣寫： 

…… 

＃i nclude “MyClass.h” 

…… 

void CMyDoc::Serialize(CArchive& ar) 

{ 

//在此調用MyClass重寫過的Serialize() 

m_MyObject. Serialize(ar); // m_MyObject為MyClass執行個體 

} 

至此，串行化工作就算完成了，一即簡單直覺：從CObject派生自己的類，重寫Serialize（）。在此過程中，我刻意安排：在沒有用到DECLARE_SERIAL/IMPLEMENT_SERIAL宏，也沒有用到CArray等模闆類的前提下就完成了串行化的工作。我看過某些書，總是一開始就講DECLARE_SERIAL/IMPLEMENT_SERIAL宏或馬上用CArray模闆，讓讀者覺得串行化就是這兩個東西，導緻許多朋友是以找不着北。 

大家看到了，沒有DECLARE_SERIAL/IMPLEMENT_SERIAL宏和CArray等資料結構模闆也依然可以完成串行化工作。 

現在可以騰出時間講一下大家覺得十分抽象的CArchive。我們先看以下程式（注：以下程式包含動态建立等，請包含DECLARE_SERIAL/IMPLEMENT_SERIAL宏） 

void MyClass::Serialize(CArchive& ar) 

{ 

if (ar.IsStoring()) //讀寫判斷 

{ 

ar<< m_pMyVar; //問題：ar 如何把m_pMyVar所指的對象變量儲存到磁盤？ 

} 

else 

{ 

pMyClass = new MyClass; //準備存儲空間 

ar>> m_pMyVar; 

} 

} 

要回答上面的問題，即“ar<<XXX”的問題。和我們得看一下模拟CArchive的代碼。 

“ar<<XXX”是執行CArchive對運算符“<<”的重載動作。ar和XXX都是該重載函數中的一參數而已。函數大緻如下： 

CArchive& operator<<( CArchive& ar, const CObject* pOb) 

{ 

………… 

//以下為CRuntimeClass連結清單中找到、識别pOb資料。 

CRuntimeClass* pClassRef = pOb->GetRuntimeClass(); 

//儲存pClassRef即類資訊（略） 

((CObject*)pOb)->Serialize();//儲存MyClass資料 

………… 

} 

從上面可以看出，因為Serialize()為虛函數，即“ar<<XXX”的結果是執行了XXX所指向對象本身的Serialize()。對于“ar>>XXX”，雖然不是“ar<<XXX”逆過程，大家可能根據動态建立和虛函數的原理料想到它。 

至此，永久儲存算是寫完了。在此過程中，我一直努力用最少的代碼，詳盡的解釋來說明問題。以前我為本課題寫過一個版本，并在幾個論壇上發表過，但不知怎麼在網上遺失（可能被删除）。是以這篇文章是我重寫的版本。記得第一個版本中，我是對DECLARE_SERIAL/IMPLEMENT_SERIAL和可串行化的數組及連結清單對象說了許多。這個版本中我對DECLARE_SERIAL/IMPLEMENT_SERIAL其中奧秘幾乎一句不提，目的是讓大家能找到中心，有更簡潔的永久儲存的概念，我覺得這種感覺很好！

說到消息，在MFC中，“最熟悉的神秘”可算是消息映射，那是我們剛開始接觸MFC時就要面對的東西。有過SDK程式設計經驗的朋友轉到MFC程式設計的時候，一下子覺得什麼都變了樣。特别是視窗消息及對消息的處理跟以前相比，更是風馬牛不相及的。如文檔不是視窗，是怎樣響應指令消息的呢？

初次用MFC程式設計，我們隻會用MFC ClassWizard為我們做大量的東西，最主要的是添加消息響應。記憶中，如果是自已添加消息響應，我們應何等的小心翼翼，對BEGIN_MESSAGE_MAP（）……END_MESSAGE_MAP()更要奉若神靈。它就是一個魔盒子，把我們的咒語放入恰當的地方，就會發生神奇的力量，放錯了，自己的程式就連“命”都沒有。

據說，知道得太多未必是好事。我也曾經打算不去了解這神秘的區域，覺得程式設計的時候知道自己想做什麼就行了。MFC外表上給我們提供了東西，直覺地說，不但給了我個一個程式的外殼，更給我們許多友善。微軟的出發點可能是希望達到“傻瓜程式設計”的結果，試想，誰不會用ClassWizard？大家知道，Windows是基于消息的，有了ClassWizard，你又會添加類，又會添加消息，那麼你所學的東西似乎學到頭了。于是許多程式員認為“我們沒有必要走SDK的老路，直接用MFC程式設計，新的東西通常是簡單、直覺、易學……”

到你真正想用MFC程式設計的時候，你會發覺光會ClassWizard的你是多麼的愚蠢。MFC不是一個普通的類庫，普通的類庫我們完全可以不了解裡面的細節，隻要知道這些類庫能幹什麼，接口參數如何就萬事大吉。如string類，操作順序是定義一個string對象，然後修改屬性，調用方法。

但對于MFC，你并不是在你的程式中寫上一句“＃i nclude MFC.h”，然後就在你的程式中用MFC類庫。

MFC是一塊包着糖衣的牛骨頭。你很輕松地寫出一個單文檔視窗，在視窗中間列印一句“I love MFC!”，然後，惡夢開始了……想逃避，打算永遠不去了解MFC内幕？門都沒有！在MFC這個黑暗神秘的洞中，即使你打算摸着石頭前行，也注定找不到出口。對着MFC這塊牛骨頭，微軟溫和、民主地告訴你“你當然可以選擇不啃掉它，咳咳……但你必然會是以而餓死！”

消息映射與指令傳遞展現了MFC與SDK的不同。在SDK程式設計中，沒有消息映射的概念，它有明确的回調函數中，通過一個switch語句去判斷收到了何種消息，然後對這個消息進行處理。是以，在SDK程式設計中，會發送消息和在回調函數中處理消息就差不多可以寫SDK程式了。

在MFC中，看上去發送消息和處理消息比SDK更簡單、直接，但可惜不直覺。舉個簡單的例子，如果我們想自定義一個消息，SDK是非常簡單直覺的，用一條語句：SendMessage(hwnd,message,wparam,lparam)，之後就可以在回調函數中處理了。但MFC就不同了，因為你通常不直接去改寫視窗的回調函數，是以隻能亦步亦趨對照原來的MFC代碼，把消息放到恰當的地方。這确實是一樣很痛苦的勞動。

要了解MFC消息映射原理并不是一件輕松的事情。我們可以逆向思維，想象一下消息映射為我們做了什麼工作。MFC在自動化給我們提供了很大的友善，比如，所有的MFC視窗都使用同一視窗過程，即所有的MFC視窗都有一個預設的視窗過程。不象在SDK程式設計中，要為每個視窗類寫一個視窗過程。

對于消息映射，最直截了當地猜想是：消息映射就是用一個資料結構把“消息”與“響應消息函數名”串聯起來。這樣，當視窗感覺消息發生時，就對結構查找，找到相應的消息響應函數執行。其實這個想法也不能簡單地實作：我們每個不同的MFC視窗類，對同一種消息，有不同的響應方式。即是說，對同一種消息，不同的MFC視窗會有不同的消息響應函數。

這時，大家又想了一個可行的方法。我們設計視窗基類（CWnd）時，我們讓它對每種不同的消息都來一個消息響應，并把這個消息響應函數定義為空虛函數。這樣，從CWnd派生的視窗類對所有消息都有了一個空響應，我們要響應一個特定的消息就重載這個消息響應函數就可以了。但這樣做的結果，一個幾乎什麼也不做的CWnd類要有幾百個“多餘”的函數，那怕這些消息響應函數都為純虛函數，每個CWnd對象也要背負着一個巨大的虛拟表，這也是得不償失的。

許多朋友在學習消息映射時苦無突破，其原因是一開始就認為MFC的消息映射的目的是為了替代SDK視窗過程的編寫——這本來沒有了解錯。但他們還有多一層的了解，認為既然是替代“舊”的東西，那麼MFC消息映身應該是更高層次的抽象、更簡單、更容易認識。但結果是，如果我們不通過ClassWizard工具，手動添加消息是相當迷茫的一件事。

是以，我們在學習MFC消息映射時，首先要弄清楚：消息映射的目的，不是為是更加快捷地向視窗過程添加代碼，而是一種機制的改變。如果不想改變視窗過程函數，那麼應該在哪裡進行消息響應呢？許多朋友一知半解地認為：我們可以用HOOK技術，搶在消息隊列前把消息抓取，把消息響應提到視窗過程的外面。再者，不同的視窗，會有不同的感興趣的消息，是以每個MFC視窗都應該有一個表把感興趣的消息和相應消息響應函數連系起來。然後得出——消息映射機制執行步驟是：當消息發生，我們用HOOK技術把本發送到視窗過程的消息抓獲，然後對照一下MFC視窗的消息映射表，如果是表裡面有的消息，就執行其對應的函數。

當然，用HOOK技術，我們理論上可以在不改變視窗過程函數的情況下，可以完成消息響應。MFC确實是這樣做，但實際操作起來可能跟你的想象差别很大。

現在我們來編寫消息映射表，我們先定義一個結構，這個結構至少有兩個項：一是消息ID，二是響應該消息的函數。如下：

struct AFX_MSGMAP_ENTRY

{

UINT nMessage; //感興趣的消息

AFX_PMSG pfn; //響應以上消息的函數指針

}

當然，隻有兩個成員的結構連接配接起來的消息映射表是不成熟的。Windows消息分為标準消息、控件消息和指令消息，每類型的消息包含數百不同ID、不同意義、不同參數的消息。我們要準确地判别發生了何種消息，必須再增加幾個成員。還有，對于AFX_PMSG pfn，實際上等于作以下聲明：

void (CCmdTarget::*pfn)();

(提示：AFX_PMSG為類型辨別，具體聲明是：typedef void (AFX_MSG_CALL CCmdTarget::*AFX_PMSG)(void);)

pfn是不一不帶參數和傳回值的CCmdTarget類型函數指針，隻能指向CCmdTarget類中不帶參數和傳回值的成員函數，這樣pfn更為通用，但我們響應消息的函數許多需要傳入參數的。為了解決這個沖突，我們還要增加一個表示參數類型的成員。當然，還有其它……

最後，MFC我們消息映射表成員結構如下定義：

struct AFX_MSGMAP_ENTRY

{

UINT nMessage; //Windows 消息ID

UINT nCode; // 控制消息的通知碼

UINT nID; //指令消息ID範圍的起始值

UINT nLastID; //指令消息ID範圍的終點

UINT nSig; // 消息的動作辨別

AFX_PMSG pfn;

};

有了以上消息映射表成員結構，我們就可以定義一個AFX_MSGMAP_ENTRY類型的數組，用來容納消息映射項。定義如下：

AFX_MSGMAP_ENTRY _messageEntries[];

但這樣還不夠，每個AFX_MSGMAP_ENTRY數組，隻能儲存着目前類感興趣的消息，而這僅僅是我們想處理的消息中的一部分。對于一個MFC程式，一般有多個視窗類，裡面都應該有一個AFX_MSGMAP_ENTRY數組。我們知道，MFC還有一個消息傳遞機制，可以把自己不處理的消息傳送給别的類進行處理。為了能查找各下MFC對象的消息映射表，我們還要增加一個結構，把所有的AFX_MSGMAP_ENTRY數組串聯起來。

于是，我們定義了一個新結構體：

struct AFX_MSGMAP

{

const AFX_MSGMAP* pBaseMap; //指向别的類的AFX_MSGMAP對象

const AFX_MSGMAP_ENTRY* lpEntries; //指向自身的消息表

};

之後，在每個打算響應消息的類中這樣聲明一個變量：AFX_MSGMAP messageMap，讓其中的pBaseMap指向基類或另一個類的messageMap，那麼将得到一個AFX_MSGMAP元素的單向連結清單。這樣，所有的消息映射資訊形成了一張消息網。

當然，僅有消息映射表還不夠，它隻能把各個MFC對象的消息、參數與相應的消息響應函數連成一張網。為了友善查找，MFC在上面的類中插入了兩個函數（其中theClass代表目前類）：

一個是_GetBaseMessageMap()，用來得到基類消息映射的函數。函數原型如下：

const AFX_MSGMAP* PASCAL theClass::_GetBaseMessageMap() \

{ return &baseClass::messageMap; } \

别一個是GetMessageMap() ，用來得到自身消息映射的函數。函數原型如下：

const AFX_MSGMAP* theClass::GetMessageMap() const \

{ return &theClass::messageMap; } \

有了消息映射表之後，我們得讨論到問題的關鍵，那就是消息發生以後，其對應的響應函數如何被調用。大家知道，所有的MFC視窗，都有一個同樣的視窗過程——AfxWndProc(…)。在這裡順便要提一下的是，看過MFC源代碼的朋友都得，從AfxWndProc函數進去，會遇到一大堆曲折與迷團，因為對于這個龐大的消息映射機制，MFC要做的事情很多，如優化消息，增強相容性等，這一大量的工作，有些甚至用彙編語言來完成，對此，我們很難深究它。是以我們要省略大量代碼，理性地分析它。

對已定型的AfxWndProc來說，對所有消息，最多隻能提供一種預設的處理方式。這當然不是我們想要的。我們想通過AfxWndProc最終執行消息映射網中對應的函數。那麼，這個執行路線是怎麼樣的呢？

從AfxWndProc下去，最終會調用到一個函數OnWndMsg。請看代碼：

LRESULT CALLBACK AfxWndProc(HWND hWnd,UINT nMsg,WPARAM wParam, LPARAM lParam)

{

……

CWnd* pWnd = CWnd::FromHandlePermanent(hWnd); //把對句柄的操作轉換成對CWnd對象。

Return AfxCallWndProc(pWnd,hWnd,nMsg,wParam,lParam);

}

把對句柄的操作轉換成對CWnd對象是很重要的一件事，因為AfxWndProc隻是一個全局函數，當然不知怎麼樣去處理各種windows視窗消息，是以它聰明地把處理權交給windows視窗所關聯的MFC視窗對象。

現大，大家幾乎可以想象得到AfxCallWndProc要做的事情，不錯，它當中有一句：

pWnd->WindowProc(nMsg,wParam,lParam);

到此，MFC視窗過程函數變成了自己的一個成員函數。WindowProc是一個虛函數，我們甚至可以通過改寫這個函數去響應不同的消息，當然，這是題外話。

WindowProc會調用到CWnd對象的另一個成員函數OnWndMsg，下面看看大概的函數原形是怎麼樣的：

BOOL CWnd::OnWndMsg(UINT message,WPARAM wParam,LPARAM lParam,LRESULT* pResult)

{

if(message==WM_COMMAND)

{

OnCommand(wParam,lParam);

……

}

if(message==WM_NOTIFY)

{

OnCommand(wParam,lParam,&lResult);

……

}

const AFX_MSGMAP* pMessageMap; pMessageMap=GetMessageMap();

const AFX_MSGMAP_ENTRY* lpEntry;

if((lpEntry=AfxFindMessageEntry(pMessageMap->lpEntries,message,0,0)!=NULL)

{

lpEntry->pfn();

}

}

以上，大家看到了OnWndMsg能根據傳進來的消息參數，查找到比對的消息和執行相應的消息響應。但這還不夠，我們平常響應菜單指令消息的時候，原本屬于架構視窗（CFrameWnd）的WM_COMMAND消息，卻可以放到視對象或文檔對象中去響應。其原理如下：

我們看上面函數OnWndMsg原型中看到以下代碼：

if(message==WM_COMMAND)

{

OnCommand(wParam,lParam);

……

}

即對于指令消息，實際上是交給OnCommand函數處理。而OnCommand是一個虛函數，即WM_COMMAND消息發生時，最終是發生該消息所對應的MFC對象去執行OnCommand。比如點架構視窗菜單，即向CFrameWnd發送一個WM_COMMAND，将會導緻CFrameWnd::OnCommand(wParam,lParam)的執行。

且看該函數原型

BOOL CFrameWnd::OnCommand(WPARAM wParam,LPARAM lParam)

{

……

return CWnd:: OnCommand(wParam,lParam);

}

可以看出，它最後把該消息交給CWnd:: OnCommand處理。再看：

BOOL CWnd::OnCommand(WPARAM wParam,LPARAM lParam)

{

……

return OnCmdMsg(nID,nCode,NULL,NULL);

}

這裡包含了一個C++多态性很經典的問題。在這裡，雖然是執行CWnd類的函數，但由于這個函數在CFrameWnd:: OnCmdMsg裡執行，即目前指針是CFrameWnd類指針，再有OnCmdMsg是一個虛函數，是以如果CFrameWnd改寫了OnCommand，程式會執行CFrameWnd::OnCmdMsg(…)。

對CFrameWnd::OnCmdMsg(…)函數原理扼要分析如下：

BOOL CFrameWnd:: OnCmdMsg(…)

{

CView pView = GetActiveView();//得到活動視指針。

if(pView-> OnCmdMsg(…))

return TRUE; //如果CView類對象或其派生類對象已經處理該消息，則傳回。

……//否則，同理向下執行，交給文檔、架構、及應用程式執行自身的OnCmdMsg。

}

到此，CFrameWnd:: OnCmdMsg完成了把WM_COMMAND消息傳遞到視對象、文檔對象及應用程式對象實作消息響應。

寫了這麼多，我們清楚MFC消息映射與指令傳遞的大緻過程。現在，我們來看MFC“神秘代碼”，會發覺好看多了。

先看DECLARE_MESSAGE_MAP()宏，它在MFC中定義如下：

#define DECLARE_MESSAGE_MAP() \

private: \

static const AFX_MSGMAP_ENTRY _messageEntries[]; \

protected: \

static AFX_DATA const AFX_MSGMAP messageMap; \

virtual const AFX_MSGMAP* GetMessageMap() const; \

可以看出DECLARE_MESSAGE_MAP()定義了我們熟悉的兩個結構和一個函數，顯而易見，這個宏為每個需要實作消息映射的類提供了相關變量和函數。

現在集中精力來看一下BEGIN_MESSAGE_MAP，END_MESSAGE_MAP和ON_COMMAND三個宏，它們在MFC中定義如下（其中ON_COMMAND與另外兩個宏并沒有定義在同一個檔案中，把它放到一起是為了好看）：

#define BEGIN_MESSAGE_MAP(theClass, baseClass) \

const AFX_MSGMAP* theClass::GetMessageMap() const \

{ return &theClass::messageMap; } \

AFX_COMDAT AFX_DATADEF const AFX_MSGMAP theClass::messageMap = \

{ &baseClass::messageMap, &theClass::_messageEntries[0] }; \

AFX_COMDAT const AFX_MSGMAP_ENTRY theClass::_messageEntries[] = \

{ \

#define ON_COMMAND(id, memberFxn) \

{ WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSig_vv, (AFX_PMSG)&memberFxn },

#define END_MESSAGE_MAP() \

{0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } \

}; \

一下子看三個宏覺得有點複雜，但這僅僅是複雜，公式性的文字代換并不是很難。且看下面例子，假設我們架構中有一菜單項為“Test”，即定義了如下宏：

BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd)

ON_COMMAND(ID_TEST, OnTest)

END_MESSAGE_MAP()

那麼宏展開之後得到如下代碼：

const AFX_MSGMAP* CMainFrame::GetMessageMap() const

{ return &CMainFrame::messageMap; }

///以下填入消息表映射資訊

const AFX_MSGMAP CMainFrame::messageMap =

{ &CFrameWnd::messageMap, &CMainFrame::_messageEntries[0] };

//下面填入儲存着目前類感興趣的消息，可填入多個AFX_MSGMAP_ENTRY對象

const AFX_MSGMAP_ENTRY CMainFrame::_messageEntries[] =

{

{ WM_COMMAND, CN_COMMAND, (WORD)ID_TEST, (WORD)ID_TEST, AfxSig_vv, (AFX_PMSG)&OnTest }, // 加入的ID_TEST消息參數

{0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } //本類的消息映射的結束項

};

大家知道，要完成ID_TEST消息映射，還要定義和實作OnTest函數。在此即要在頭檔案寫afx_msg void OnTest()并在源檔案中實作它。根據以上所學的東西，我們知道了當ID為ID_TEST的指令消息發生，最終會執行到我們寫的OnTest函數。