mfc
已經江河日下，日漸式微，而
gtk+
可謂欣欣向榮，如日中天。這裡無意於落井下石，痛打落水狗，貶
mfc而尊
gtk+
。自己即在使用
mfc也在使用
gtk+
，不會偏袒其中之任何一方。這個對比完全出於個人對兩者的理解，說它是不完全對比，一方面只是一時興起想做個筆記而已，另外一方面我對兩者的理解也是有限的。 1.
兩者都是基於物件導向設計的。儘管
mfc是用
c++寫的，而
gtk+是用c
寫的，但思想都是物件導向的。
gtk+
使用glib
的物件機制，由於用
c寫的，其實現相對有點繁瑣。 2.
兩者都是基於訊息驅動的。這是
gui系統的共性，訊息可以是硬體上報的，如滑鼠事件、鍵盤事件和觸控螢幕等等，也可以是程式產生，如乙個視窗給另外乙個視窗傳送了乙個訊息。但兩者並不完全相同，
gtk+
通過select
掛在多個檔案描述符上，可以同時等待多個事件源，比如
socket
、子程序退出和核心事件等等，而
mfc只能通過
getmessage
掛到訊息佇列上。 3.
兩者都不是執行緒安全的，即只有乙個執行緒可以操作
gui資源。主要是出於效能的考慮，這個問題不大，因大多數應用程式都是單執行緒的。而且它們都提供一些機制，讓其它執行緒可以在必要時操作
gui資源。在
gtk+
中可以通過
idle
函式來實現，在
mfc中可以通過
postmessage
來實現(
附帶說明一下：
win32
原生的gui api
是執行緒安全的)。
4.gtk+
整合了一系列的基礎函式庫，功能強大，而
mfc孤軍做戰，勢單力薄。
glib
是gtk+
的基本庫，裡面實現了常見的容器和演算法，可謂應有盡有，同時隔離了平台相關的功能。
pango
是gtk+
用於文字渲染的函式庫，它負責控制不同文字的
layout
布局，而把字模的繪製交給
freetype
等字型函式庫處理。
mfc雖然實現了一些容器，但數量不多也不好用，除了對原生
gui api
的包裝外，沒提供多少其它功能，與
microsoft foundation class library
這個名稱一點都不相稱。 5.
gtk+
是跨平台的，而
mfc則不是。
gtk+
在設計時就考慮了可移植性，它按分層模型來組織整個系統，
glib
封裝了依賴於
os平台的函式，提供一套抽象的介面，在不同的平台有不同的實現。
gdk封裝了依賴於輸入
/輸出裝置的功能，如鍵盤事件的獲取和顯示緩衝的輸出，同時實現了基本的繪圖功能。
gtk+
幾乎可以在所有
pc平台下執行，而
mfc從來都沒有考慮過可移植性，它是與
win32 gui
繫結在一起的。 6.
gtk+
小巧，而
mfc笨重。
gtk+
編譯出來的可執行檔案約
3m左右，而
mfc本身雖然不大，但它各種版本加在一起就可觀了。
mfc有
ansi
版本、有
unicode
版、有debug
版、有release
版、還有一些組合，如果你因此而暈倒了，那是很正常的。 7.
gtk+
的使用簡單，
mfc的使用繁瑣。
gtk+
的使用比較簡單，即使在沒有工具的幫助下，要寫乙個
gtk+
的應用程式也不難，實際上絕大多數
gtk+
應用程式都是一行**一行**的敲出來的。而
mfc的使用則太麻煩了，很難想象沒有
vc的嚮導的幫助，寫乙個基於
mfc的應用程式。即有了
vc的嚮導，仍有大量的程式設計師說
mfc很難用。 8.
gtk+
使用signal
機制，解開訊息源與訊息目標之間耦合。而
mfc使用訊息，將訊息源與訊息目標硬編碼在一起。
signal
的好處是，不需要知道目標是誰，誰關心誰就註冊，這種出版訂閱機制是解耦的最佳方式。而
mfc的訊息則是必須知道目標是誰，把訊息源與訊息目標死死的綁在一起。
mfc提供了一套文件
/檢視框架，實現了類似出版訂閱的功能，這本是設計者引以自豪的東西，結果因為太複雜不能被人理解，反而為開發人員所詬病。 9.
gtk+
採用layout
機制動態計算各子視窗的座標位置，自適應螢幕大小的變化。而
mfc要求子視窗的座標位置硬編碼，結果要適應不同解析度的螢幕非常困難。
gtk+
在視窗布局時分為兩個階段，第乙個階段父視窗先詢問子視窗的最佳大小，第二個階段父視窗根據自己的大小計算子視窗的實際大小，子視窗根據實際大小進行調整。
10.gtk+
採用容器機制來合理分離控制項的職責，
mfc沒有容器這個概念，很難實現遞迴組合。
gtk+
中差不多所有控制項都是容器，都可以容納其它任何控制項，而
mfc只有頂層視窗才是容器，可以容納其它子控制項。容器這個概念對**重用的影響非常之大，這裡舉兩個例子：其一是帶的按鈕
(bitmapbutton)
，在gtk+
中它就是
gtkimage
和gtklabel
的組合，而在
mfc中，和文字都要自己繪製。前者的
gtkimage
和gtklabel
可以在很多地方重用，而後都的繪製**和事件處理**只有自己才能使用。其二是列表框，在
gtk+
中，它只是乙個容器，你可以向裡面放編輯器、下拉框和其它任何者你想得到的控制項。而在
mfc中，即使只是實現乙個不同外觀的列表框，你都要採用自繪的方式，**重用非常困難，向列表框中加入其它控制項就更麻煩了，要使用一些非同尋常的手段不可。
11.gtk+
採用容器機制優先使用組合而不是繼承，符合現代設計的原則。
mfc強制使用繼承，使用麻煩而且耦合緊密。
gtk+
應用程式不需要繼承任何視窗。
mfc應用程式必須繼承對話方塊或者其它頂層視窗才行，雖然可以採用中介者模式，把控制項之間的互動集中在頂層視窗中，不需要繼承控制項，但仍然很麻煩。
GTK 與MFC不完全對比
gtk 與mfc 不完全對比 mfc 已經江河日下，日漸式微，而gtk 可謂欣欣向榮，如日中天。這裡無意於落井下石，痛打落水狗，貶mfc而尊gtk 自己即在使用mfc也在使用gtk 不會偏袒其中之任何一方。這個對比完全出於個人對兩者的理解，說它是不完全對比，一方面只是一時興起想做個筆記而已，另外一方...
GTK 與MFC不完全對比
1.兩者都是基於物件導向設計的。儘管mfc是用c 寫的，而gtk 是用c寫的，但思想都是物件導向的。gtk 使用glib的物件機制，由於用c寫的，其實現相對有點繁瑣。2.兩者都是基於訊息驅動的。這是gui系統的共性，訊息可以是 硬體上報的，如滑鼠事件 鍵盤事件和觸控螢幕等等，也可以是程式產生，如乙個...
GTK 與MFC不完全對比
mfc已經江河日下，日漸式微，而gtk 可謂欣欣向榮，如日中天。這裡無意於落井下石，痛打落水狗，貶mfc而尊gtk 自己即在使用mfc也在使用gtk 不會偏袒其中之任何一方。這個對比完全出於個人對兩者的理解，說它是不完全對比，一方面只是一時興起想做個筆記而已，另外一方面我對兩者的理解也是有限的。1....