开发工具大比拼之Visual C VS Delphi

　　引言

　　"Visual C 与Delphi之比较"最近在CSDN的论坛上的讨论非常火热，本文将以一个程序员的角度，从技术水平、功能、性能、易用性、稳定性、发展历程和前景等方面，以Visual C 6和Delphi5为代表，尽可能客观地比较介绍Visual C 和Delphi这两大主流开发工具的优缺点，其中将涉及到语言、应用框架、控件、编译和连接、集成界面、调试、COM、数据库开发等。本文还将对如何选择使用这两个开发工具提出一些建议。

　　值得一提的是，由于C Builder与Delphi同为Inprise公司产品，它们除了使用的语言不同，其余特性几乎都相同。因此本文对C Builder程序员和学习者也有参考价值。

　　语言：存在即是合理

　　首先声明常被混淆的一点：VC和Delphi本身不是语言，而是开发平台。它们所用的语言分别是略作扩展的C/C 和Object Pascal。我在网上常看到有人问应该学C/C 还是VC，这个问题很好回答：如果你学VC你就必须得学C/C ，或者说你学会了VC也就学会了C/C 了。

　　言归正传，我们来比较一下C 和Object Pascal的优缺点。有人认为Object Pascal是"玩具语言"，C 才是"专业语言"，这是不对的。单从语言本身看，Object Pascal与C 属同一重量级。它们都是完全支持面向对象的语言，都扎根于"历史悠久"的面向过程的语言。C 是由C发展而来的，Object Pascal由Pascal进化而来。它们都有很强的灵活性，都有自己的特长和不足。比如说，Object Pascal不支持多重继承、模板、操作符重载、内联函数定义、预处理、宏、全局静态类变量、嵌套类定义，等等，而这些都是C 支持的。但同样地C 也不支持Object Pascal的虚构造函数、过程嵌套、内置集合类型、内置字符串类型、"finally"构造等等，在RTTI方面Object Pascal也比C 做得好。但这些并不重要，因为可以通过其它方式达到同样的目的，比如C 可以通过类扩展支持集合、字符串，Object Pascal可以通过"interface"多重继承，等等。关键是二者都可以很好地完成你手头的任务，这就够了。

　　但是，仅仅比较语言本身是不够的，还得看它们的被接受和流行程度，学习曲线，发展前途，可移植性等，以及，很重要但常常被忽略的一点：与开发环境(指VC与Delphi)及其应用框架的"磨合"程度。

　　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）程序调试的断点行可能和代码行不同；２）没有将最新的代码信息综合进去；３）容易产生错误的逻辑；４）因为读错文件头而很容易产生类似"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存在的不足。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有