QT和MFC的差別

在使用MFC之前就已經使用Qt這個事實可能影響了我的客觀性。

（MFC效率較高，但大量的Windows API和訊息機制使得其較難理解，不易用；QT封裝較好，易用且跨平臺，但效率較低）

文章從實用主義的觀點出發：我的老闆給我一份軟體的規劃說明，並且讓我來開發。其中一些我用Qt來開發，而另外一些我使用MFC來開發。

MFC（微軟基礎類庫）是專門為windows設計的一個用於開發圖形使用者介面的類庫。MFC或多或少使用了面向物件的方法包裝了Win32的API，正因如此，這些API有時是C++，有時是C，甚至是C和C＋＋的混合體。

Qt這個C++的圖形庫由Trolltech在1994年左右開發。它可以執行在Windows,Mac OS X, Unix，還有像Sharp Zaurus這類嵌入式系統中。Qt是完全面向物件的。

Document/View model
MFC程式設計需要使用Document/View模式以及模板(template),如果不使用的話，程式設計將變得異常困難。而且，模板(template) 設定了固定的結構，若所需結構乃模板未定義之結構，則程式設計難已。例如，劃分一區域使顯示兩個檢視(view)於兩個文件(document)。還有一個經 常的問題是：模板(template)建立了檢視(view)卻無法訪問(access)它，文件（document）要做完所有事情，但是這經常會出現 問題。

Qt不強制使用任何設計模式。如果你認為恰當，使用Document/view沒有任何問題。不使用也沒有任何問題。

偽物件 vs 真物件
歸根結底，Qt和MFC的差異在於其設計的差異。

MFC的根本目的是訪問包裝起來的用C語言寫的windows的API。 這絕非好的面向物件的設計模式，在很多地方，你必須提供一個包含15個成員的C語言的struct，但是其中只有一個與你所期望的相關，或者必須用舊式的引數來呼叫你的函式。

MFC還有許多讓人摸不著頭腦的地方，函式名沒有任何的連續性。比如，如果你建立了一個graphical類，直到呼叫了creat()以後該類才會被創 建。然而對dialogs，必須要等到OnInitDialog()才能建立這個物件。奇怪的是到了views,建立該類的函式名竟然成了 OnInitUpdate(),......你自己建立一個類用他們的方式呼叫它，你的程式崩潰了。

比如說有一個dialog包含CEdit控制元件，如果沒有呼叫DoModal()你就不能使用GetWindowText()。否則將會莫名其妙的失敗。總之，MFC充滿了丈二和尚摸不著頭腦的事情，並且，這種錯誤很難除錯。

Qt恰恰相反，它的架構明顯是經過精心設計的面向物件的。Qt因此在命名，繼承，類的組織等方面保持了優秀的一致性。你只需要提供唯一一個方法的引數，僅 此一個。在不同的類中呼叫方式也是有很強的連貫性。返回值也很有邏輯性。所有一切達到了簡單和強大的和諧統一。一旦你使用了其中一個類，其他的類也就觸類 旁通，因為他們是一致的。

在Qt中可以利用Edit控制元件，用C++建立類的方法來建立自己的QLineEdit。永遠可以馬上訪問任何的方法，不管它是顯示還是隱藏。在這裡沒有迷局，一切都按照你認為的簡單的方式來運作。

訊息迴圈
MFC是事件驅動的架構。要執行任何操作，都必須是對特定的訊息作出響應。Windows對應用程式傳送的
資訊數以千計，遺憾的是，要分清楚這些分繁蕪雜的訊息是很困難的，並且關於這方面的文件並不能很好的解決這些問題。

Qt的訊息機制是建立在SIGNAL()傳送和SLOT()接受的基礎上的。這個機制是物件間建立聯絡的核心機制。利用SIGNAL()可以傳遞任何的參 數。他的功能非常的強大。可以直接大傳遞訊號給SLOT()，因此可以清楚的理解要發生的事情。一個類所傳送的訊號的數量通常非常的小(4或者5)，並且 文件也非常的齊全。這讓你感覺到一切盡在掌握之中。SIGNAL/SLOT機制類似於Java中listener機制,不過這種機制更加輕量級，功能更齊 全。

建立介面
MFC無法建立大小動態可變的子視窗，必須重新手動修改程式碼來改變視窗的位置（這恰好解釋了為什麼windows裡的dialog是不可以改變的）這個問 題在軟體進行國際化翻譯的時候更加嚴重，因為許多國家表達相同意思需要更長的詞彙和句子，必須要對每個語言的版本重新修改自己的軟體。

在Qt中，任何東西都可以手動的敲出來，因為它很簡單：為了得到一個button，可以這樣些

button = new PushButton( "buttonName", MyParentName );

如果想在按下某個按鈕以後想呼叫某斷程式碼的執行，可以這樣寫：

connect( button, SIGNAL( clicked() ), qApp, SLOT( action() ) );

Qt擁有非常簡單而又不失強大的layout機制，以至於不使用它就是在浪費時間了。

Qt還提供了一個圖形使用者工具，Qt Designer，可以用來幫助建立使用者介面。可以修改所使用的任何控制元件的屬性。不用將他們放在嚴格的位置，可以通過layout完美的組織他們。這個工 具所產生的程式碼我們是可以實際上閱讀並且可以理解的。生成的程式碼單獨放在一個檔案裡，在程式設計的同時，你可以隨心所欲的多次重新生成使用者介面。

Qt Designer可以讓你完成許多在MFC中不可能完成的任務，比如用預先填好的生成listview，在每個tab上用不同的view來使用tab 控制。

幫助文件
使用者選擇圖形開發環境的時候，幫助文件是否周全是左右其選擇的重要因素。Visual的開發環境的幫助文件MSDN(這個還要單獨掏錢購買)非常的龐大， 有10個CDROM光碟。他包羅永珍，涵蓋廣泛。但是難免有泥沙俱下，主題模糊，關鍵資訊不突出的遺憾。其連結設計的也很糟糕，通過連結很難從一個類跳轉 到其父類或者子類以及相關的類。如果你搜索一個關鍵字，不管是Visual C++, Visual J++, Visual Basic，只要包含這些關鍵字的資訊統統的返回來。

Qt的文件設計的相當優秀。你可以到doc.tolltech.com上面一睹芳容。

Qt的文件完備且詳細的覆蓋了Qt的方方面面，竟然僅有18M。每一個類和方法都被詳盡描述，鉅細靡遺，舉例充實。通過Trolltech公司提供的連結 或者是Qt Assistant工具，可以方便的從一個類或者方法跳轉到其他的類。文件還包含了一個初學者教程和一些典型應用的例子。同時還提供了FAQ和郵件列表， 方便通過Internet或者使用者群來查閱。如果你購買了授權，在一天之內你將會得到Trolltech公司的技術支援。

實際上，Qt優秀的幫助文件使得尋求外部幫助的機會大大減少。Tolltech公司的一個宗旨是：有如此優秀的Qt產品以及其幫助文件，技術支援是多餘的。

Unicode
使用MFC，如果要顯示unicode，在編譯連結的時候必須用到特殊的引數(和改變可執行檔案執行的入口)，必須在每個string前面加上T，將 char修改成TCHAR，每個字串處理函式(strcpy(), strdup(), strcat()...... )都要改變成另外的函式名。更令人惱火的是支援Unicode的軟體竟然不能和不支援Unicode的DLL一起工作。當使用外部DLL來開發的時候這是 個很嚴重的問題，但是你毫無選擇。

使用Qt，字串用QString來處理，其本身是與生俱來的Unicode.不需要改變什麼東西。不要在編譯/連結時候增添引數，不要修改程式碼，只需要使用QString就可以了。

QSting類功能強大，你可以廣泛的使用它，並且不要擔心Unicode問題。這使得轉換為Unicode非常的方便。QSting提供了轉換為char ＊ 和UTF8的函式。

顯然，MFC的CString的設計相比於Qt的QString設計有著巨大的不同。CString以char ＊為基礎提供了很少的功能。它的優點是當需要char ＊型別的時候，可以直接使用CString型別。乍看起來這個好像是個優點，其實實質上還是有很大的缺陷的，特別是可以直接修改char * 而不要更新類。在轉變為Unicode的時候這個也碰到很大的麻煩。

相反，QString在內部以unicode儲存string，需要時提供char ＊功能。實際上很少用到char ＊，因為整個Qt的API用文字的方式響應QString引數。QString還附帶許多其他的功能，比如自動分享QString的內容。這是一個非常強 大的類，你會喜歡在很多地方用它的。

國際化
使用MFC是可以國際化的，但是需要將每一個字串放在一個字串表中，在程式碼中到處使用LoadString(IDENTIFIET)。然後轉化這些資 源到DLL中，翻譯字串到所需要的語言，改變圖形介面，然後呼叫程式使用這個DLL。整個過程是如此的繁瑣，可謂牽一髮而動全身。考慮的事情要面面俱 到。

使用Qt的時候，只需要將字串置於函式tr()中，在程式開發中這算是舉手之勞。可以直接在程式碼中改變字串的參考。Qt Linguist,Qt的一個工具，能夠提取所有待翻譯的string並按照友好的介面顯示出來。這個使用者介面非常適合翻譯，使用字典，顯示字串內容， 恰當的unicode顯示，快捷方式衝突檢測，檢測未翻譯的字串，檢測字串修改情況，功能齊全。這個軟體可以供沒有任何程式設計經驗的翻譯者使用。同時該 軟體在GPL的版權下發布，可以按照你的需求來修改它。
翻譯以後的文件儲存在XML中，適合軟體複用的原則。為軟體增加一種新的語言版本僅僅是用Qt Linguist產生一個新的檔案而已。

resources問題
使用MFC，一部分開發過程要依靠“resources”,在很多的案例中開發者必須使用他們。這樣會導致如下的後果：

出了Visual Studio，你很難使用其他的工具來完成開發。
資源編輯器僅有有限的功能，比如：通過Dialog編輯器不可能改變所有的屬性，一些屬性可以改變，另一些屬性則不可能改變。(譯者注：下面還有兩條陳述MFC缺點的例項，但我感覺這些已經夠說明問題了，暫時刪節不譯)
然而Qt並沒有資源的概念，這就解決了以上所提到的問題。Qt提供了一個指令碼使得能將編入你的程式碼。對於介面設計，Qt Designer則建立了可讀的程式碼。

價格
一旦你購買了Visual Studio，你將免費的獲得MFC SDK。

Qt在Unix上是可以免費獲得其遵守GPL版權的版本(譯者注:現在在windows 上也可以免費獲得其GPL版本)。如果要開發不公開原始碼的軟體，必須購買Qt的授權。在特定平臺下，每個開發者購買一個永久性授權，並獲得一年的技術支 持。(譯者注：後面關於購買價格等問題刪去，因為價格不固定，如果有疑問請到官方網站查詢價格)

釋出
在釋出基於MFC的軟體時，必須依靠存在於客戶電腦上的MFC。但是這是不安全的，同樣是MFC42.dll，可以基於相同的庫得到3個不同的版本。通 常，需要檢查是否擁有正確的MFC42.dll版本，如果不是，就升級它。但是升級MFC42.dll會改變很多軟體的行為。這讓我感到很不舒服，如果用 戶在安裝我的軟體以後導致其機器宕機該怎麼辦？

Qt則沒有這個風險，因為Qt壓根就沒有“升級整個系統”這個概念。

感覺MFC相比QT的確有很多的不足，但MFC的使用者群巨大。Qt要想短時間撼動MFC的地位，還是有點難度的

參考：https://www.cnblogs.com/congdiaodiao/p/4599180.html