分享
 
 
 

开发工具大比拼之Visual C++ VS Delphi(摘自delphi园地)

王朝vc·作者佚名  2006-01-10
窄屏简体版  字體: |||超大  

开发工具大比拼之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)程序调试的断点行可能和代码行不同;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)高,但编程效率较低。鱼和熊掌不可兼得嘛。

VCL比之MFC的另一优点是对异常处理的支持,而一大缺点是对多线程支持差。VCL的大部分都不是针对多线程优化的。虽说VCL提供了简化多线程操作的类,但只是工作者线程(worker threads)使用起来比较简单。如果线程要和界面打交道的话事情就变得麻烦了,因为除了应用程序的主线程,任何线程不能访问任何可视的VCL部件。你不得不使用Synchronize方法等待主线程处理它的消息,然后在主线程中访问VCL部件。而MFC就没有这样的限制。

稳定性与完善程度:VC是老大哥

VC要比Delphi稳定和完善。VC的发展历史比Delphi长,微软的总体实力比Inprise强。VC的框架MFC经历了那么多年的发展和完善,功能非常全面,而且十分稳定,bug很少。其中你可能遇到的bug也更少。而且有第三方的专门工具帮助你避开这些bug。如此规模的一个类库,能做到这一点不容易。不要小看了这一点,很多专业程序员就是为这个选择VC的。因为尽管VCL比MFC的抽象程度高,封装较为高层,但由此带来的开发效率的提高对高手来说毕竟是有限的。而如果你遇到一个怪问题,调试了半天,发现不是你的代码有错,而是VCL的bug,你作何感想?虽说遇到这类问题的可能性很小,但对VCL的形象的影响可不小。Delphi的IDE太占资源,启动速度太慢,和某些显卡驱动程序冲突,VCL中有bug,调试器不够健壮,对不稳定的第三方控件没有防护措施 …… 问题多多,在这方面Delphi不如VC。希望Inprise能更上一层楼。顺便说一下,我们在网上看到有些人极言Delphi的不稳定,说几分钟出现20多次非法操作。Delphi的确不如Visual C++稳定,但也不至于如此呀。我估计是那位朋友的Delphi装了某些有问题的第三方控件,导致了Delphi的频频出错。不妨卸下那些控件试试?

可移植性:立足现实,放眼未来

Inprise正在开发Delphi的Linux版本,代号为Kylix。也许通过Kylix,用VCL构架编写的Windows程序向Linux移植成为可能。但这只是可能。因为在目前Inprise的兼容性工作做得并不好。低版本的Delphi不能使用高版本的VCL组件,而高版本的Delphi竟然不能使用低版本的VCL组件。真是岂有此理,我们很少看见软件有不向下二进制兼容的。如果Windows 98不能运行95的程序,Windows 95不能运行3.x的程序,Win 3.x不能运行DOS程序,你还会用Windows吗?如果Windows 95的程序必须经过重新编译才能在98下运行,98会卖得那么好吗?"同门兄弟"C++Builder和Delphi也不能互相使用对方的组件,甚至同一套VCL库的文件名也不一样。所以一个组件有for D1/D2/D3/D4/D5/C1/C3/C4/C5这些不同版本是常有的事,而且随着Delphi和C++Builder版本的升级可能还会增加。希望Inprise能先解决同门兄弟的兼容性问题。而微软的VC就没有这类问题。MFC1.0的程序也可以毫无障碍地在VC6.0下编译通过。

集成界面:宏观与微观

就大处说,VC的集成界面是不如Delphi的。Delphi仅仅一个Object Inspector就可以将VC的一堆Wizards比下去,何况它还有Code Explorer、ToDo List等。但从小处,又可以看出Delphi的不成熟。比如"自动完成"功能的智能化程度和提示详细程度不如VC,响应速度也没有VC快。

Visual C++所带的MSDN是一部"开发者的百科全书",信息庞大,查询方便,这方面比Delphi更专业。很多帮助项都有源程序示范。

Delphi的OpenTools是完全面向第三方的开放系统,开发者可以修改很多Borland公司自身的功能,从IDE的可扩充性上说Delphi更好。

调试:细微之处见真功

Visual C++和Delphi的调试功能都非常强大,同时都具有单步可视化调试、断点跟踪、运行时改变变量、鼠标指向可以得到变量值等等功能。对DLL的输入输出也能方便的管理,能够进行源码级别的调试。

相对而言,Visual C++能够更加方便地看到变量的变化情况,这包括对结构可以展开成数据树,从而了解每一个变量的值,每一步调试,变化了的变量会加红,从而使调试更加方便。另外,Visual C++的块内存察看比Delphi也要方便。

当然,Delphi也有很多体贴的细微之处,比如在线程调试的时候,Delphi能够很方便地察看线程的变化,Visual C++却必须要弹出一个模式对话框。

数据库开发:Delphi一枝独秀

数据库支持是Delphi的强项。这主要体现在Delphi与BDE的无缝集成,以及Delphi提供的那一大堆现成的数据库操作控件。这是VC望尘莫及的。目前Delphi支持BDE、ADO、InterBase三种数据库访问方式。所有的方式都能拖拉到应用程序中实现可视化操作。正是因为Delphi对数据库类的包装,使得用户操作数据库不像在Visual C++中必须从开始到最后都要干预。明显地提高了开发速度。

Delphi中使用WebBroker控件还能很方便地构造出基于数据库的Web页面,通过HTML管理Web数据库。 Visual C++访问数据主要通过ADO和OLEDB,很多ActiveX控件也能添加数据库功能。但是没有像Paradox这样的桌面数据库,Access相对功能太弱了。也许SQL Server是不错的选择。

COM:新技术的力量

COM是组件对象模型的缩写。它是OLE和ActiveX技术的基础,COM定义了一组API和一个二进制标准,让不同的编程语言、不同平台的彼此独立的对象相互进行通讯。

COM是Microsoft制订的行业标准。但Delphi也为COM提供了强大的语言支持。支持接口、variant、宽字符串功能。这些对COM的封装确实比C++更方便。比如在C++(没有类框架)进行COM编程时,变体定义为oaidl.h文件中的VARIANT结构。要处理变体,必须手工调整oleaut32.dll中VariantXXXX()API函数对其进行初始化和管理,如VariantInit()、VariantCopy()、VariantClear()等等。

Visual C++实现COM编程有一种特殊的方法就是使用ATL。ATL使用Visual C++特有的多重继承来实现COM接口。虽然不见得实现COM服务和控制更容易,但是ATL和最新COM技术的接口,基于模板的构造都比Delphi强。ATL更有利于建立小巧、快捷的COM组件程序。

按目前通用的观点,Visual C++应用到COM服务程序更有优势,Delphi应用到COM组件程序更合适。

昨天,今天,明天

技术的进步在很多时候是此消彼长的。当初Borland的Turbo C和Borland C++几乎是C/C++程序员唯一的选择。微软的Quick C(现在还有人知道这个产品吗?)和Microsoft C/C++从来也没有成为过主流。但Borland C++又流行了多少年呢?不久就被新崛起的Microsoft Visual C/C++压下去了。于是Inprise(原Borland)拣起了当年Turbo Pascal和Borland Pascal的辉煌(事实上Borland的成名作就是第一个Pascal编译器),全力推出了Delphi。Delphi当初推出时被称为VB杀手,但VB现在仍然活得挺好。毕竟微软是靠Basic起家的嘛,VB不是那么容易被打败的。Inprise想了想不和VB争了,使用Delphi的IDE和VCL配上C++语言,推出了C++Builder,又向Visual C++的市场发起了夹攻。C++Builder似乎是个不错的折衷选择了?再仔细想想!C++Builder的优点Delphi都有,但Delphi的优点C++Builder未必有。比如C++Builder的编译速度比VC还慢,哪能和Delphi比?而且因为VCL是Object Pascal写的,C++语言和VCL磨合得并不好。C++Builder的bug比Delphi还多,甚至Sample代码中还有错。VCL的部分功能不能使用,要靠嵌入pascal代码访问。C++Builder可用的第三方控件远没有Delphi多。

唉,真是金无足赤。Microsoft和Inprise,谁会笑在最后呢?

鱼和熊掌:艰难的选择

选择一个开发工具依赖于很多不同的因素,每个人都能因为某种语言的某个缺陷而放弃学习或使用这种语言。任何程序员都希望自己喜欢的工具能达到理想的境界,通过上面不完善的比较,我想大家都有自己的看法。我们认为影响大家选择开发语言的因素主要包括:

1) 哪门语言更容易入门?

学习一种语言需要投入大量的时间和精力。开发程序的开发成本是值得考虑的现实。一个熟练的Delphi程序员和一个熟练的VC程序员工作效率是一样的。但是,成为熟练的程序员必须很快掌握一门语言的技巧。不幸的是,目前熟练的Visual C++程序员是十里挑一。相对而言,Delphi更适合初学者。

2) 哪门语言有更多可继承的代码?

语言代码的可重用性是加快开发效率明显方面,从早期的过程、函数到现在的组件技术都是朝这个目标在奋斗。这两种语言对代码重用的理解是不一样的,Delphi主要通过VCL控件来实现代码重用,Visual C++实现起来就比较复杂。

3) 语言自身的本性。

就技术(主要指应用框架)来说,Delphi目前领先于Visual C++。但稳定性和健壮性的不足又让我对Inprise"想说爱你不容易"。而VC尽管发展到今日已十分完善,但MFC框架已是明日黄花了。如果不使用MFC,目前又没有合适的替代品。根据你的需要和实际情况做选择吧。实际上Visual C++和Delphi也不是简单竞争关系。它们在许多领域并不重叠,甚至是互补的。到底怎样取舍,要根据你的项目特性决定。如果你开发系统底层的东西,需要极好的兼容性和稳定性,选Visual C++吧。你可以只调用Windows的各种API,不用MFC。如果你写传统的Windows桌面应用程序,Visual C++的MFC框架是"正统"的选择;如果界面部分占这个应用程序代码比例较大的话,或者Delphi中有相关功能的控件的话,Delphi是事半功倍的选择。如果你为企业开发数据库、信息管理系统等高层应用("高层"是相对于"低层/底层"而言的,不是说技术高级或低级),而且有比较紧的期限限制,选Delphi比较好。如果你熟悉的语言是Object Pascal,又不打算学复杂的C++,那么Delphi几乎是唯一的选择。传统的观点是:Delphi适合编写Internet/Intranet、表格制图、数据库操作、高级用户界面等等。Visual C++适合编写设备驱动、COM服务程序、科学计算、控制台(console)程序、WinCE的应用和一些小的工具等等。应用范围的不同要求好的程序员同时精通这两门语言。

4) 语言的前景和可扩充性。

Delphi是Inprise的旗舰产品之一,前景应当还是比较乐观的,而且Inprise已经在向Linux进军了,而微软还迟迟没有动作。遗憾的是,Inprise公司Delphi的创始人已经跳槽到微软去主持Visual J++和C#项目了。但愿对Inprise冲击不会太大。

微软的Visual C++的前景又怎样呢?Visual Studio 7.0就要推出了。这一版本将加强网络开发的特性。看来微软虽然被判解体,开发实力可是一点没打折扣。

另外,虽说MFC已稍显落后,但不是说它不值得学。事实上,不学MFC就等于没学VC。利用MFC框架开发程序仍然是目前开发桌面应用的主流模式,而且还会保持相当长的时间。微软公司CEO史蒂夫·巴尔默(Steve Ballmer)曾说,.NET流行还得等2-3年。那么,MFC至少还有2-3年的生命空间。在技术日新月异的IT界,2-3年实在是很长一段时间了。好好把握吧。即使你不使用MFC框架,花点时间看一下MFC的封装机制对你熟悉C++的OOP机制和Windows底层功能也是很有好处的。而VCL的源代码是Object Pascal的,对C/C++程序员就没有这个"额外"的作用了。

参考文献:

Programming Microsoft Visual C++, 5th Edition, by Scot Wingo & George Shepherd

MSDN, by Microsoft Corp.

Visual C++ versus Delphi, by John M. Jacobson BorlandC++Builder3Unleashed,byCharlieCalvert,etal.

Borland Delphi 5-Developer's Guide,by Inprise Corp.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有