MFC與QT區別

QT使用的編譯器是MinGW，即Linux下的GCC移植到windows的版本；MFC使用的編譯器是Visual C++

QT的應用主要在Linux下，可是它自己是跨平臺的，也支持其餘操做系統，是如今比較著名的界面庫，著名的KDE就是使用QT開發的。MFC是提供給VC的，可是它主要是代碼庫，不像VCL和編譯器掛鉤不少，可是MFC主要是對windows API的封裝，因此只能用於windows平臺

根據你所說的方面，簡單比較一下：
1.開發速度
總體來講可能MFC會快捷一些，由於windows平臺的開發工具大多很智能，由於立足於windows的開發人羣很廣，從菜鳥到專業人士，可是QT因爲基於Linux，可用的開發工具很少，大都比較專業，可能是第三方產品，並且集成度不大，第三方庫也沒有MFC的多，從這一點MFC略勝一籌，可是QT自從被Nokia收購後，官方發佈了跨平臺集成開發環境QTCreator，因此以後走向就很差說了，我的整體感受QT Creator和VS.net差距比較大，還需改進
可是從庫自己來講QT集成的功能較MFC龐大，並且使用的封裝技術信號和槽也是比較受到讚許的，好比QT Script爲QT提供嵌入式腳本，QT界面庫支持CSS，因此QT作出來的界面比MFC要好，並且比較容易，MFC就須要藉助第三方庫了。由於MFC是淺層封裝（最新的2008 sp1加入了BCG的高級界面庫，可能有所改善）windows SDK，以下降使用windows SDK引發的開發效率的下降，和開發難度的增長。因此QT庫是比MFC優秀的，兩個庫都經受了時間的考驗，穩定性都很高，Bug幾乎沒有
2.運行效率
MFC因爲其淺層封裝的特色，因此運行效率是比較高的，加上vc對windows的針對性優化，總體性能是比較高的，可是若是加入第三方庫就不敢保證了QT由於庫比較龐大，封裝層次較深，因此運行效率較MFC爲低，可是在如今的機器配置下，C#你們都不介意了，這些會引發人們的介意嗎？
3.應用範圍，如今windows的普及範圍誰能比過，因此MFC的客戶量比較多，QT主要是Linux下的開發人員在使用，但MFC也只是得益於windows（感受又是一次捆綁戰略），MFC不支持嵌入式開發（主要指手機平臺），可是QT有對應的模塊

4.學習難度
QT的封裝哲學比較明晰，和系統隔離的比較好，因此我的感受門檻不高
MFC較難精通，由於深刻開發以後SDK仍是要了解的，不然程序感受比較兒童化，呵呵
最近用了一段時間Qt，以爲網上這篇文章講述Qt與MFC之間的區別很到位，分享一下。

----------------------------------原文----------------------------------------------------

我曾經使用過QT和MFC來開發過軟件，我想和你們分享我使用他們時所體會的不一樣之處。

我並不是一個職業做家，這篇文章可能看起來不如專業的雜誌和網站上的那麼條理清晰。可是，我在這裏是用我本身的語言來表達我本身的經驗，但願能和你分享。英語比不是個人母語，因此可能會有一些用詞古怪，詞句錯誤之處，請發信給我，我能夠改正他們。

本文不想僞裝客觀公正，我只想表述我使用的經驗。文中不會逐條的列舉Qt和MFC各自的優缺點。我在使用MFC以前就已經使用Qt這個事實可能影響了個人客觀性。

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

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

Qt這個C++的圖形庫由Trolltech在1994年左右開發。它能夠運行在Windows,Mac OSX, Unix，還有像Sharp Zaurus這類嵌入式系統中。Qt是徹底面向對象的。Document/View modelMFC編程須要使用Document/View模式以及模板(template),若是不使用的話，編程將變得異常困難。並且，模板(template)設定了固定的結構，若所需結構乃模板未定義之結構，則編程難已。例如，劃分一區域使顯示兩個視圖(view)於兩個文檔(document)。還有一個常常的問題是：模板(template)建立了視圖(view)卻沒法訪問(access)它，文檔（document）要作完全部事情，可是這常常會出現問題。 (這種數據和視圖分開的設計模式也是一種不錯的模式，不該該成爲否認MFC的理由)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充滿了丈二和尚摸不着頭腦的事情，而且，這種錯誤很難調試。 （誠然，MFC是爲了封裝Window API。用MFC比WinowsAPI會簡單些，但確實有些函數的調用時機、前後順序，若是不是用過一段時間，確實可能

所以致使問題）

Qt偏偏相反，它的架構明顯是通過精心設計的面向對象的。Qt所以在命名，繼承，類的組織等方面保持了優秀的一致性。你只須要提供惟一一個方法的參數，僅此一個。在不一樣的類中調用方式也是有很強的連貫性。返回值也頗有邏輯性。全部一切達到了簡單和強大的和諧統一。一旦你使用了其中一個類，其餘的類也就舉一反三，由於他們是一致的。在Qt中能夠利用Edit控件，用C++建立類的方法來建立本身的QLineEdit。永遠能夠立刻訪問任何的方法，無論它是顯示仍是隱藏。在這裏沒有迷局，一切都按照你認爲的簡單的方式來運做。

 

消息循環

MFC是事件驅動的架構。要執行任何操做，都必須是對特定的消息做出響應。Windows對應用程序發送的

信息數以千計，遺憾的是，要分清楚這些分繁蕪雜的消息是很困難的，而且關於這方面的文檔並不能很好的解決這些問題。

Qt的消息機制是創建在SIGNAL()發送和SLOT()接受的基礎上的。這個機制是對象間創建聯繫的核心機制。利用SIGNAL()能夠傳遞任何的參數。他的功能很是的強大。能夠直接大傳遞信號給SLOT()，所以能夠清楚的理解要發生的事情。一個類所發送的信號的數量一般很是的小(4或者5)，而且文檔也很是的齊全。這讓你感受到一切盡在掌握之中。SIGNAL/SLOT機制相似於Java中listener機制,不過這種機制更加輕量級，功能更齊全。（這種機制確實貌似簡單清晰了一些）

 

建立界面

MFC沒法建立大小動態可變的子窗口 ，必須從新手動修改代碼來改變窗口的位置（這剛好解釋了爲何windows裏的dialog是不能夠改變的）這個問題在軟件進行國際化翻譯的時候更加嚴重，由於許多國家表達相贊成思須要更長的詞彙和句子，必需要對每一個語言的版本從新修改本身的軟件。

在Qt中，任何東西均可以手動的敲出來，由於它很簡單：爲了獲得一個utton，能夠這樣些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 控制。 （界面方面Qt確實很好很強大）

 

幫助文檔

用戶選擇圖形開發環境的時候，幫助文檔是否周全是左右其選擇的重要因素。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產品以及其幫助文檔，技術支持是多餘的。

(MSDN用熟了很好用，很全面，相關的背景知識，例子都能找到。並且網上還有豐富的例程能夠參考。僅憑Qt的幫助文檔絕對不足以解決全部問題，而網上我只找了個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的時候這個也碰到很大的麻煩。（CString隨編譯選項能夠是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產生一個新的文件而已。（這點Qt作的很不錯。）

resources問題

使用MFC，一部分開發過程要依靠「resources」,在不少的案例中開發者必須使用他們。這樣會致使以下的後果：出了Visual Studio，你很難使用其餘的工具來完成開發。 資源編輯器僅有有限的功能，好比：經過Dialog編輯器不可能改變全部的屬性，一些屬性能夠改變，另外一些屬性則不可能改變。(譯者注：下面還有兩條陳述MFC缺點的實例，但我感受這些已經夠說明問題了，暫時刪節不譯)

然而Qt並無資源的概念，這就解決了以上所提到的問題。Qt提供了一個腳本使得能將編入你的代碼。對於界面設計，Qt Designer則建立了可讀的代碼。 (Qt Designer設計界面很不錯)

價格

一旦你購買了Visual Studio，你將免費的得到MFC SDK。Qt在Unix上是能夠免費得到其遵照GPL版權的版本(譯者注:如今在windows 上也能夠免費得到其GPL版本)。若是要開發不公開源代碼的軟件，必須購買Qt的受權。在特定平臺下，每一個開發者購買一個永久性受權，並得到一年的技術支持。(譯者注：後面關於購買價格等問題刪去，由於價格不固定，若是有疑問請到官方網站查詢價格)

發佈

在發佈基於MFC的軟件時，必須依靠存在於客戶電腦上的MFC。可是這是不安全的，一樣是MFC42.dll，能夠基於相同的庫獲得3個不一樣的版本。一般，須要檢查是否擁有正確的MFC42.dll版本，若是不是，就升級它。可是升級MFC42.dll會改變不少軟件的行爲。這讓我感到很不舒服，若是用戶在安裝個人軟件之後致使其機器死機該怎麼辦？

Qt則沒有這個風險，由於Qt壓根就沒有「升級整個系統」這個概念。（若是不是一個版本的Qt,仍是會有問題的）

速度

MFC是專爲Windows設計的，而Qt是跨平臺的。因此MFC編寫的程序的運行速度、響應時間都優於Qt