浅析Visual C++如何选取对象框架

风中清淡 2010-01-14

Visual C++采用的框架是MFC,但是许多人对MFC还不算很了解,其实这个并不难理解,MFC是实际上是微软提供的,用于在C++环境下编写应用程序的一个框架和引擎,更好的为Visual C++进行工作的框架。

这本来是优点,但很有意思的是,正因为如此,微软写MFC时必须考虑最大限度减少对语言本身的改动,而把功夫下在源代码级,以便能尽可能支持ANSI等标准,结果导致MFC的封装复杂而不直观。

太多的宏定义和含义模糊且自动生成、不得改动的注释使MFC乃至VC让很多新手望而生畏,不敢"下水"深入学习。而Object Pascal几乎是Inprise"专用"的,不必考虑"标准"问题,因此Inprise写VCL时就把全部精力放在了结构与性能上,结果语言与框架的磨合程度非常好。VCL框架的结构清晰,VCL代码的可读性非常好。许多人说Delphi比较容易上手,也是这个缘故。天下没有白吃的午餐。你要工业标准吗?你要可移植性吗(关于可移植性和兼容性,下文会详细比较)?那么请面对MFC的"天书"级代码吧。

编译和连接:The Need For Speed
不同的语言带来的另一个不同是,编译和连接的速度的不同,以及执行速度的不同。Delphi的编译和连接速度,毫不夸张地说,比VC快几十倍。即使把VC的Incremental Link选项打开,Delphi的编译和连接速度仍比VC快好几倍。并不是说微软的编译器不行,这是由C++的复杂性决定的。

模板的处理、预处理和宏的展开都是很费时的。前文不是提到Object Pascal没有模板、预处理和宏吗?这本来是缺点,但带来的一个好处就是编译速度极快。至于编译完的二进制代码,在打开相同的优化选项的情况下,Delphi和VC执行速度并没有太大的差别。

为了克服编译的速度问题,C++编译器一般需要增强的连接器和预处理机制。但是预处理机制仍然存在若干问题:
1)程序调试的断点行可能和代码行不同;
2)没有将最新的代码信息综合进去;
3)容易产生错误的逻辑;
4)因为读错文件头而很容易产生类似"Unexpected End of File"的错误。

两个编译器有个共同点是都能识别无用的"死"代码,比如一个没有用的函数等等。编译后的程序将不包含这些多余的信息。Delphi在这方面作得更加出色。它可以让你在编辑器中可视化地提示出那行代码是"活"的、那行代码是"死"的。这样你就能整理出最精简的代码。

Delphi在编译后将在左边显示一个小蓝点表示这行代码是"活"的。Visual C++做不到这点。 Delphi编译后可执行文件至少有200K(如果不使用VCL,仅仅使用WinAPI,文件的大小将大大缩小)但是Visual C++编程使用MFC编译后的可执行文件通常只有几十K,主要是因为微软已经将系统运行库包含在Windows系统了(Borland公司曾经和微软协商这个接口,但是微软利用操作系统的优势不愿意公开)。

同样道理,使用BDE开发的的数据库程序必须附带3-5M的额外系统文件,也是非常不协调的。 非常有趣的是,Delphi能够使用由C++ Builder创建的的OBJ文件,但是使用上受很大的局限性。最后,Visual C++的编译和连接时的错误信息比Delphi要详细和具体的多。特别是使用ATL开发更加如此。

应用框架:MFC?有KFC流行吗?
应用程序框架(Application Frame),有时也称为对象框架。Visual C++采用的框架是MFC。MFC不仅仅是人们通常理解的一个类库(同样,Delphi的VCL也不仅仅是一个控件库,尽管它的名字叫"可视控件库")。你如果选择了MFC,也就选择了一种程序结构,一种编程风格。

MFC早在Windows 3.x的时代就出现了,那时的Visual C++还是16位的。经过这些年的不断补充和完善,MFC已经十分成熟。但由于原型出现得比较早,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)高,但编程效率较低。鱼和熊掌不可兼得嘛。

相关推荐