,MFC 相比 于 VCL 落后了一个时代。 尽管微软对 MFC 的更新没有停止, 我也经常读到"只要 Windows 不过时,MFC 就不会过时"之类观点的文章,但就象 Inprise(原 Borland)的 OWL 框架的淡 出一样,MFC 的淡出也是早晚的事。其实 MFC 是和 OWL 同一个时代的产物。OWL 已经 不在了,MFC 怎能不"居安思危"呢?如果 MFC 青春永驻,微软的开发人员也不会"私自" 开发出基于 ATL 的 WTL 呀。当然,WTL 的地位不能和 MFC 比,它并不是微软官方支持 的框架,封装的功能也相当有限。但至少也反衬出了 MFC 存在的不足。 我们以为,最能体现一个应用程序框架的先进性的是它的委托模型,即对 Windows 消 息的封装机制。对 Windows API 的封装就不用说了吧。大同小异,也没什么技术含量。如 果高兴,你也可以自己写一个类库来封装。但对 Windows 消息驱动机制的封装就不是那 么容易的了。最自然的封装方式是采用虚成员函数。如果要响应某个消息就重载相应的虚 函数。但出乎我的意料,MFC 采用的是"古老"的宏定义方法。用宏定义方法的好处是省去 了虚函数 VTable 的系统开销(由于 Windows 的消息种类很多,开销不算太小)。不过带来 的缺点就是映射不太直观。对于 MFC,则是"太不直观"了。它的消息映射代码虽然是可见 的,但"劝君莫碰"。好在 VC 的 ClassWizard 可以自动生成消息映射代码,使用起来还算 方便。但和 VCL 的委托模型相比,MFC 的映射方法就显得太落后了。而 Delphi 的 Object Pascal 因为没有"标准负担",语言引入了组件、
事件处理、属性等新特性。由于功夫做在 编译器级,生成的
源代码就显得十分简洁。似乎 VC 是"让框架迁就语言",而 Delphi 是" 让语言迁就框架"。 我想举一个对字符串操作的封装的例子来说明 MFC 和 VCL 的优缺点。在 MFC 中, CStringList 类有加入、获取、删除等功能,但 VCL 的 TStringList 类除了上述功能还有排 序、从逗号分隔的字串读入、流输入输出等功能。但同样的字符串替换功能,VCL 的 StringReplace 要比 MFC 的 CString::Replace 慢 2-3 倍。 总的来说, VCL 的封装比 MFC 更为高层,更为抽象,但不可避免地带来的问题是某些部分执行效率比 MFC 略低。这就 象低级语言(如汇编)的执行效率比高级语言(如 Basic)高,但编程效率较低。鱼和熊掌不可 兼得嘛。 VCL 比之 MFC 的另一优点是对异常处理的支持,而一大缺点是对多线程支持差。VCL 的大部分都不是针对多线程优化的。 虽说 VCL 提供了简化多线程操作的类, 但只是工作者 线程(worker threads)使用起来比较简单。如果线程要和界面打交道的话事情就变得麻烦
了,因为除了应用程序的主线程,任何线程不能访问任何可视的 VCL 部件。你不得不使用 Synchronize 方法等待主线程处理它的消息,然后在主线程中访问 VCL 部件。而 MFC 就 没有这样的限制。 稳定性与完善程度:VC 是老大哥 VC 要比 Delphi 稳定和完善。VC 的发展历史比 Delphi 长,微软的总体实力比 Inprise 强。VC 的框架 MFC 经历了那么多年的发展和完善,功能非常全面,而且十分稳定,bug 很少。其中你可能遇到的 bug 也更少。而且有第三方的专门工具帮助你避开这些 bug。如 此规模的一个类库,能做到这一点不容易。不要小看了这一点,很多专业程序员就是为这 个选择 VC 的。因为尽管 VCL 比 MFC 的抽象程度高,封装较为高层,但由此带来的开发 效率的提高对高手来说毕竟是有限的。而如果你遇到一个怪问题,调试了半天,发现不是 你的代码有错,而是 VCL 的 bug,你作何感想?虽说遇到这类
问题的可能性很小,但对 VCL 的形象的影响可不小。Delphi 的 IDE 太占资源,启动速度太慢,和某些显卡驱动程序 冲突,VCL 中有 bug,调试器不够健壮,对不稳定的第三方控件没有防护措施 …… 问题 多多,在这方面 Delphi 不如 VC。希望 Inprise 能更上一层楼。顺便说一