GTK+與MFC不完全對比

轉載地址：[url]http://bbs.chinaunix.net/archiver/tid-868226.html[/url]

[轉]GTK+與MFC不完全對比

[color=Red]今天看到一篇關於GTK+和MFC對比的文章,學GTK+編程的來看看[/color]

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應用程序必須繼承對話框或者其它頂層窗口才行，雖然可以採用中介者模式，把控件之間的交互集中在頂層窗口中，不需要繼承控件，但仍然很麻煩。

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

4.  pango 不好, 垃圾.

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

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



8, 9. 聽着好像BeOS API挺好的. signal也不錯
------->
無聊的比較.
MFC與windows掛鉤
GTK與lX掛鉤的
系統運行模式不同,
比較起來,很荒唐.
-------->
這篇文章比較的荒唐，歸其原因無非是因MFC框架機制複雜，自己用起來不能得心應手而已。如果學習者能夠貫通MFC的整套的框架，不需過於深入只需瞭解其 運行機制，在學習類似文章提到的東西往往能遊刃有餘，感覺很是輕鬆！現在說MFC江河日下用者寥寥無幾，大部分原因是因爲MFC難度頗大，從項目管理方面 上考慮的（如：開發週期、人員素質等）。其中不少人也是因爲對事一知半解不求真諦，對其的一種誤判。對深入研究過MFC框架的朋友們，應該會了解“空有屠 龍之術，卻無龍可屠。”這句話的含義，看似無奈，卻道出英雄孤寂的真正感覺！

最近正在學用qt，這裏舉個例子就多說一些，部分書上到處宣揚信號與槽比回調機制好，我承認的確比較方便。但我不喜歡這種方便，就是這種簡單矇蔽了多數程序員的雙眼，我相信大多數人還是喜歡到兔子洞走一遭的。