[轉(zhuǎn)]GTK+與MFC不完全對比

elution

今天看到一篇關(guān)于GTK+和MFC對比的文章,學GTK+編程的來看看

MFC已經(jīng)江河日下，日漸式微，而GTK+可謂欣欣向榮，如日中天。這里無意于落井下石，痛打落水狗，貶MFC而尊GTK+。自己即在使用MFC也在使用GTK+，不會偏袒其中之任何一方。這個對比完全出于個人對兩者的理解，說它是不完全對比，一方面只是一時興起想做個筆記而已，另外一方面我對兩者的理解也是有限的。

1.         兩者都是基于面向?qū)ο笤O計的。盡管MFC是用C++寫的，而GTK+是用C寫的，但思想都是面向?qū)ο蟮摹�GTK+使用glib的對象機制，由于用C寫的，其實現(xiàn)相對有點繁瑣。

2.         兩者都是基于消息驅(qū)動的。這是GUI系統(tǒng)的共性，消息可以是硬件上報的，如鼠標事件、鍵盤事件和觸摸屏等等，也可以是程序產(chǎn)生，如一個窗口給另外一個窗口發(fā)送了一個消息。但兩者并不完全相同，GTK+通過select掛在多個文件描述符上，可以同時等待多個事件源，比如socket、子進程退出和內(nèi)核事件等等，而MFC只能通過GetMessage掛到消息隊列上。

3.         兩者都不是線程安全的，即只有一個線程可以操作GUI資源。主要是出于性能的考慮，這個問題不大，因大多數(shù)應用程序都是單線程的。而且它們都提供一些機制，讓其它線程可以在必要時操作GUI資源。在GTK+中可以通過idle函數(shù)來實現(xiàn)，在MFC中可以通過PostMessage來實現(xiàn)(附帶說明一下：Win32原生的GUI API是線程安全的)。

4.         GTK+整合了一系列的基礎(chǔ)函數(shù)庫，功能強大，而MFC孤軍做戰(zhàn)，勢單力薄。Glib是GTK+的基本庫，里面實現(xiàn)了常見的容器和算法，可謂應有盡有，同時隔離了平臺相關(guān)的功能。Pango是GTK+用于文字渲染的函數(shù)庫，它負責控制不同文字的layout布局，而把字模的繪制交給freetype等字體函數(shù)庫處理。MFC雖然實現(xiàn)了一些容器，但數(shù)量不多也不好用，除了對原生GUI API的包裝外，沒提供多少其它功能，與Microsoft Foundation Class Library這個名稱一點都不相稱。

5.         GTK+是跨平臺的，而MFC則不是。GTK+在設計時就考慮了可移植性，它按分層模型來組織整個系統(tǒng)，Glib封裝了依賴于OS平臺的函數(shù)，提供一套抽象的接口，在不同的平臺有不同的實現(xiàn)。GDK封裝了依賴于輸入/輸出設備的功能，如鍵盤事件的獲取和顯示緩沖的輸出，同時實現(xiàn)了基本的繪圖功能。GTK+幾乎可以在所有PC平臺下運行，而MFC從來都沒有考慮過可移植性，它是與Win32 GUI綁定在一起的。

6.         GTK+小巧，而MFC笨重。GTK+編譯出來的可執(zhí)行文件約3M左右，而MFC本身雖然不大，但它各種版本加在一起就可觀了。MFC有ansi版本、有unicode版、有debug版、有release版、還有一些組合，如果你因此而暈倒了，那是很正常的。

7.         GTK+的使用簡單，MFC的使用繁瑣。GTK+的使用比較簡單，即使在沒有工具的幫助下，要寫一個GTK+的應用程序也不難，實際上絕大多數(shù)GTK+應用程序都是一行代碼一行代碼的敲出來的。而MFC的使用則太麻煩了，很難想象沒有VC的向?qū)У膸椭�，寫一個基于MFC的應用程序。即有了VC的向?qū)В�仍有大量的程序員說MFC很難用。

8.         GTK+使用signal機制，解開消息源與消息目標之間耦合。而MFC使用消息，將消息源與消息目標硬編碼在一起。Signal的好處是，不需要知道目標是誰，誰關(guān)心誰就注冊，這種出版訂閱機制是解耦的最佳方式。而MFC的消息則是必須知道目標是誰，把消息源與消息目標死死的綁在一起。MFC提供了一套文檔/視圖框架，實現(xiàn)了類似出版訂閱的功能，這本是設計者引以自豪的東西，結(jié)果因為太復雜不能被人理解，反而為開發(fā)人員所詬病。

9.         GTK+采用layout機制動態(tài)計算各子窗口的坐標位置，自適應屏幕大小的變化。而MFC要求子窗口的坐標位置硬編碼，結(jié)果要適應不同分辨率的屏幕非常困難。GTK+在窗口布局時分為兩個階段，第一個階段父窗口先詢問子窗口的最佳大小，第二個階段父窗口根據(jù)自己的大小計算子窗口的實際大小，子窗口根據(jù)實際大小進行調(diào)整。

10.     GTK+采用容器機制來合理分離控件的職責，MFC沒有容器這個概念，很難實現(xiàn)遞歸組合。GTK+中差不多所有控件都是容器，都可以容納其它任何控件，而MFC只有頂層窗口才是容器，可以容納其它子控件。容器這個概念對代碼重用的影響非常之大，這里舉兩個例子：其一是帶圖片的按鈕(BitmapButton)，在GTK+中它就是GtkImage和GtkLabel的組合，而在MFC中，圖片和文字都要自己繪制。前者的GtkImage和GtkLabel可以在很多地方重用，而后都的繪制代碼和事件處理代碼只有自己才能使用。其二是列表框，在GTK+中，它只是一個容器，你可以向里面放編輯器、下拉框和其它任何者你想得到的控件。而在MFC中，即使只是實現(xiàn)一個不同外觀的列表框，你都要采用自繪的方式，代碼重用非常困難，向列表框中加入其它控件就更麻煩了，要使用一些非同尋常的手段不可。

11.     GTK+采用容器機制優(yōu)先使用組合而不是繼承，符合現(xiàn)代設計的原則。MFC強制使用繼承，使用麻煩而且耦合緊密。GTK+應用程序不需要繼承任何窗口。MFC應用程序必須繼承對話框或者其它頂層窗口才行，雖然可以采用中介者模式，把控件之間的交互集中在頂層窗口中，不需要繼承控件，但仍然很麻煩。

whyglinux

很好的文章。

為了尊重作者的勞動，建議注明轉(zhuǎn)載出處和作者名稱。

savageranthony

我也不喜歡MFC，但還是有一點不同的意見，做什么東西都不要太主觀。

原帖由 elution 于 2006-12-10 10:33 發(fā)表
今天看到一篇關(guān)于GTK+和MFC對比的文章,學GTK+編程的來看看

MFC已經(jīng)江河日下，日漸式微，而GTK+可謂欣欣向榮，如日中天。這里無意于落井下石，痛打落水狗，貶MFC而尊GTK+。自己即在使用MFC也在使用 GTK+，不會偏袒其中之任何一方。這個對比完全出于個人對兩者的理解，說它是不完全對比，一方面只是一時興起想做個筆記而已，另外一方面我對兩者的理解也是有限的。

MFC的日漸式微和GTK+的如日中天沒有可比性，
沒見過GTK+在Windows平臺的"如日中天",
而且兩種情況都是針對特定群體。

1.         兩者都是基于面向?qū)ο笤O計的。盡管MFC是用C++寫的，而GTK+是用C寫的，但思想都是面向?qū)ο蟮�。GTK+使用glib的對象機制，由于用C寫的，其實現(xiàn)相對有點繁瑣。

令人覺得麻煩的是 GTK+ 寫的東西長度怎么那么長...

2.         兩者都是基于消息驅(qū)動的。這是GUI系統(tǒng)的共性，消息可以是硬件上報的，如鼠標事件、鍵盤事件和觸摸屏等等，也可以是程序產(chǎn)生，如一個窗口給另外一個窗口發(fā)送了一個消息。但兩者并不完全相同，GTK+通過select掛在多個文件描述符上，可以同時等待多個事件源，比如socket、子進程退出和內(nèi)核事件等等，而MFC只能通過GetMessage掛到消息隊列上。

兩種方式各有優(yōu)缺點，從效率來說，我比較偏向 MessageQueue 方式。

3.         兩者都不是線程安全的，即只有一個線程可以操作GUI資源。主要是出于性能的考慮，這個問題不大，因大多數(shù)應用程序都是單線程的。而且它們都提供一些機制，讓其它線程可以在必要時操作GUI資源。在GTK+中可以通過idle函數(shù)來實現(xiàn)，在MFC中可以通過PostMessage來實現(xiàn)(附帶說明一下： Win32原生的GUI API是線程安全的)。

GTK+ 在 v1.2 后的版本在特定情況下是可以做到線程安全的，gdk_threads_enter/gdk_threads_leave
MFC 是不建議你在不明白相應條件下使用多線程，而建議從工作者線程(聽著怎么那么別扭) PostMessage 到主線程去處理。

4.         GTK+整合了一系列的基礎(chǔ)函數(shù)庫，功能強大，而MFC孤軍做戰(zhàn)，勢單力薄。Glib是GTK+的基本庫，里面實現(xiàn)了常見的容器和算法，可謂應有盡有，同時隔離了平臺相關(guān)的功能。Pango是GTK+用于文字渲染的函數(shù)庫，它負責控制不同文字的layout布局，而把字模的繪制交給freetype等字體函數(shù)庫處理。MFC雖然實現(xiàn)了一些容器，但數(shù)量不多也不好用，除了對原生GUI API的包裝外，沒提供多少其它功能，與Microsoft Foundation Class Library這個名稱一點都不相稱。

當你真正用 pango 去處理實際的東西時你會發(fā)覺他除了所謂的功能強大外就是效率低下。
不要一味的否定 MFC, 它是沒有必要再去實現(xiàn)或包裝一些 Win32 API 已經(jīng)有的東西。

5.         GTK+是跨平臺的，而MFC則不是。GTK+在設計時就考慮了可移植性，它按分層模型來組織整個系統(tǒng)，Glib封裝了依賴于OS平臺的函數(shù)，提供一套抽象的接口，在不同的平臺有不同的實現(xiàn)。GDK封裝了依賴于輸入/輸出設備的功能，如鍵盤事件的獲取和顯示緩沖的輸出，同時實現(xiàn)了基本的繪圖功能。GTK +幾乎可以在所有PC平臺下運行，而MFC從來都沒有考慮過可移植性，它是與Win32 GUI綁定在一起的。

GTK+ 不能幾乎可以在所有PC平臺下運行，它運行的最好的也就是在 X Window 下而已。
MFC 不可能考慮跨操作系統(tǒng)，最多就是 X86/PowerPC/MIPS 等。

6.         GTK+小巧，而MFC笨重。GTK+編譯出來的可執(zhí)行文件約3M左右，而MFC本身雖然不大，但它各種版本加在一起就可觀了。MFC有ansi版本、有unicode版、有debug版、有release版、還有一些組合，如果你因此而暈倒了，那是很正常的。

你看看 GTK+ 依賴的庫就不會說 GTK+ 小巧，而 MFC 依賴的庫同樣 GTK+ for Win32 都需要。

7.         GTK+的使用簡單，MFC的使用繁瑣。GTK+的使用比較簡單，即使在沒有工具的幫助下，要寫一個GTK+的應用程序也不難，實際上絕大多數(shù)GTK+ 應用程序都是一行代碼一行代碼的敲出來的。而MFC的使用則太麻煩了，很難想象沒有VC的向?qū)У膸椭�，寫一個基于MFC的應用程序。即有了VC的向?qū)В�仍有大量的程序員說MFC很難用。

"GTK+的使用簡單，MFC的使用繁瑣" 不敢茍同
即使沒有任何向?qū)�，我可以只�?gvim+gcc+msdn 寫 MFC 的程序，你信不信，事實上也有很多人這么做。
VC 的傻瓜向?qū)Ш?Glade 的界面編輯一樣，要知道原來基礎(chǔ)的東西才能事半功倍，否則就一樣是誤認子弟。

8.         GTK+使用signal機制，解開消息源與消息目標之間耦合。而MFC使用消息，將消息源與消息目標硬編碼在一起。Signal的好處是，不需要知道目標是誰，誰關(guān)心誰就注冊，這種出版訂閱機制是解耦的最佳方式。而MFC的消息則是必須知道目標是誰，把消息源與消息目標死死的綁在一起。MFC提供了一套文檔/視圖框架，實現(xiàn)了類似出版訂閱的功能，這本是設計者引以自豪的東西，結(jié)果因為太復雜不能被人理解，反而為開發(fā)人員所詬病。

GTK+ 的 signal 機制只是由于它是因 glib 引起的必然而已，不要把它吹的如何如何。
X Window/Win32 API 等哪個不是用消息隊列，存在這么久必然有其道理。
個人更偏向于使用那種隨時可以把消息轉(zhuǎn)來轉(zhuǎn)去的消息隊列，如 BeOS API，你說它耦合性太強吧，易用就好

9.         GTK+采用layout機制動態(tài)計算各子窗口的坐標位置，自適應屏幕大小的變化。而MFC要求子窗口的坐標位置硬編碼，結(jié)果要適應不同分辨率的屏幕非常困難。GTK+在窗口布局時分為兩個階段，第一個階段父窗口先詢問子窗口的最佳大小，第二個階段父窗口根據(jù)自己的大小計算子窗口的實際大小，子窗口根據(jù)實際大小進行調(diào)整。

GTK+ 的 layout 你在試試在 table 中去自由控制吧，除非你用后來才實現(xiàn)的 fixed。
理想中: 又能自由控制位置，又能根據(jù)最佳大小調(diào)整。我只在 BeOS API 中見過。

10.     GTK+采用容器機制來合理分離控件的職責，MFC沒有容器這個概念，很難實現(xiàn)遞歸組合。GTK+中差不多所有控件都是容器，都可以容納其它任何控件，而MFC只有頂層窗口才是容器，可以容納其它子控件。容器這個概念對代碼重用的影響非常之大，這里舉兩個例子：其一是帶圖片的按鈕 (BitmapButton)，在GTK+中它就是GtkImage和GtkLabel的組合，而在MFC中，圖片和文字都要自己繪制。前者的 GtkImage和GtkLabel可以在很多地方重用，而后都的繪制代碼和事件處理代碼只有自己才能使用。其二是列表框，在GTK+中，它只是一個容器，你可以向里面放編輯器、下拉框和其它任何者你想得到的控件。而在MFC中，即使只是實現(xiàn)一個不同外觀的列表框，你都要采用自繪的方式，代碼重用非常困難，向列表框中加入其它控件就更麻煩了，要使用一些非同尋常的手段不可。

要是你想，同樣可以給 MFC 增加象容器的功能。

11.     GTK+采用容器機制優(yōu)先使用組合而不是繼承，符合現(xiàn)代設計的原則。MFC強制使用繼承，使用麻煩而且耦合緊密。GTK+應用程序不需要繼承任何窗口。MFC應用程序必須繼承對話框或者其它頂層窗口才行，雖然可以采用中介者模式，把控件之間的交互集中在頂層窗口中，不需要繼承控件，但仍然很麻煩。

繼承不是好辦法，但"繼承+消息"確是你永遠想不到的理想。
MFC 也是可以類似 QT 的 SIGNAL/SLOT 的。
GTK+ 使用 signal 機制，不要說現(xiàn)代，其實就是消息驅(qū)動，它也有繼承的機制，你寫個 GtkWidget 就知道。

assiss

GTK+ 在 v1.2 后的版本在特定情況下是可以做到線程安全的，gdk_threads_enter/gdk_threads_leave
＝＝＝＝＝
這恰恰說明了gtk+的函數(shù)不是線程安全的。

Seu_why

牛人！

zjzfb

至少從使用者數(shù)量來說
GTKs遠遠比不上MFC
沒有最好，只有最適合自己的

netfarming

感覺這是一位牛人
qt和mfc比較一下更好！

qijiayan

unfair somehow

yamae

新入門～～學習一下～～

mistletoezju

1. gtk+ 的面對對象用C, 寫起來確實繁瑣, 中間加一層會好些.

4.  pango 不好, 垃圾.

5. 要mfc沒必要去跨平臺, 除非gates傻了

6. gtk+依賴庫編譯的順序,版本都易出問題. 3m多, 那是gtk-1.x的吧, 還得裁減過的.
這點上ms的東西好多了, 沒必要深究的, 繁瑣的事它們給你整好了. 你關(guān)注你自己的就行了.



8, 9. 聽著好像BeOS API挺好的. signal也不錯.

11. 繼承+消息, 好處在哪, 牛人提點提點!