我在使用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的地位，仍是有點難度的windows