荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: wayman (wayman), 信区: Program
标 题: 开发工具大比拚之Visual C++ vs. Delphi(一)
发信站: 荔园晨风BBS站 (Mon Apr 16 17:17:31 2001), 转信
引言
“visual c++与delphi之比较”最近在csdn的论坛上的讨论非常火热，本文将
以一个程序员的角度，从技术水平、功能、性能、易用性、稳定性、发展历程和前
景等方面，以visual c++ 6和delphi 5为代表，尽可能客观地比较介绍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++编译器一般需要增强的连接器和预处理机制。
但是预处理机制仍然存在若干问题：
１）程序调试的断点行可能和代码行不同。
２）没有将最新的代码信息综合进去。
３）容易产生错误的逻辑。
４）因为读错文件头而很容易产生类似“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文件，但是使用上
受很大的局限性。
顺便提一下vc的“edit and continue”功能。在调试中，这个功能是可以大
幅度节省时间的，但仍不能和delphi的闪速编译比。
最后，visual c++的编译和连接时的错误信息比delphi要详细和具体的多。特
别是使用atl开发更加如此。
--
can't nobody take my pride!!!
can't nobody hold me down!!!
※ 来源:·荔园晨风BBS站 bbs.szu.edu.cn·[FROM: 192.168.0.73]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店