自我放逐。。。
<script>MFC已经江河日下,日渐式微,而GTK+可谓欣欣向荣,如日中天。这里无意于落井下石,痛打落水狗,贬MFC而尊GTK+。自己即在使用MFC也在使用GTK+,不会偏袒其中之任何一方。这个对比完全出于个人对两者的理解,说它是不完全对比,一方面只是一时兴起想做个笔记而已,另外一方面我对两者的理解也是有限的。
function StorePage(){d=document;t=d.selection?(d.selection.type!='None'?d.selection.createRange().text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://www.365key.com/storeit.aspx?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t),'keyit','scrollbars=no,width=475,height=575,left=75,top=20,status=no,resizable=yes'));keyit.focus();}
</script>
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应用程序必须继承对话框或者其它顶层窗口才行,虽然可以采用中介者模式,把控件之间的交互集中在顶层窗口中,不需要继承控件,但仍然很麻烦。
[此贴子已经被作者于2007-8-28 9:23:26编辑过]