VC 和 Delphi 作为开发平台,很重要的一点就是提供了一个"无所不包"的应用框 架: 的 MFC 和 Delphi 的 VCL。 VC 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++采用的 框架是 MFC。MFC 不仅仅是人们通常理解的一个类库(同样,Delphi 的 VCL 也 不仅仅是一个控件库,尽管它的名字叫"可视控件库")。你如果选择了 MFC,也 就选择了一种程序结构,一种编程风格。MFC 早在 Windows 3.x 的时代就出现 了,那时的 Visual C++还是 16 位的。经过这些年的不断补充和完善,MFC 已 经十分成熟。但由于原型出现得比较早,MFC 相比于 VCL 落后了一个时代。尽 管微软对