VC和Delphi作为开发平台,很重要的一点就是提供了一个"无所不包"的应用框架:VC的MFC和Delphi的VCL
。MFC是用C++写的,VCL是用Object Pascal写的。当然,我们都知道,C++的使用范围比Object Pascal广
得多,移植性也好得多。这本来是优点,但很有意思的是,正因为如此,微软写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++采用的框架