DELPHI优缺点.docx
《DELPHI优缺点.docx》由会员分享，可在线阅读，更多相关《DELPHI优缺点.docx（8页珍藏版）》请在冰豆网上搜索。
DELPHI优缺点
推荐你一篇不错的文章，或许对你有些帮助。
VC和Delphi作为开发平台，很重要的一点就是提供了一个"无所不包"的应用框架：
VC的MFC和Delphi的VCL。
MFC是用C++写的，VCL是用ObjectPascal写的。
当然，我们都知道，C++的使用范围比ObjectPascal广得多，移植性也好得多。
这本来是优点，但很有意思的是，正因为如此，微软写MFC时必须考虑最大限度减少对语言本身的改动，而把功夫下在源代码级，以便能尽可能支持ANSI等标准，结果导致MFC的封装复杂而不直观。
（尤其是它对消息的封装，下文还会提到）。
太多的宏定义和含义模糊且自动生成、不得改动的注释使MFC乃至VC让很多新手望而生畏，不敢"下水"深入学习。
而ObjectPascal几乎是Inprise"专用"的，不必考虑"标准"问题，因此Inprise写VCL时就把全部精力放在了结构与性能上，结果语言与框架的磨合程度非常好。
VCL框架的结构清晰，VCL代码的可读性非常好。
许多人说Delphi比较容易上手，也是这个缘故。
天下没有白吃的午餐。
你要工业标准吗？
你要可移植性吗（关于可移植性和兼容性，下文会详细比较）？
那么请面对MFC的"天书"级代码吧。
编译和连接：
TheNeedForSpeed
不同的语言带来的另一个不同是，编译和连接的速度的不同，以及执行速度的不同。
Delphi的编译和连接速度，毫不夸张地说，比VC快几十倍。
即使把VC的IncrementalLink选项打开，Delphi的编译和连接速度仍比VC快好几倍。
并不是说微软的编译器不行，这是由C++的复杂性决定的。
模板的处理、预处理和宏的展开都是很费时的。
前文不是提到ObjectPascal没有模板、预处理和宏吗？
这本来是缺点，但带来的一个好处就是编译速度极快。
至于编译完的二进制代码，在打开相同的优化选项的情况下，Delphi和VC执行速度并没有太大的差别。
为了克服编译的速度问题，C++编译器一般需要增强的连接器和预处理机制。
但是预处理机制仍然存在若干问题：
1）程序调试的断点行可能和代码行不同；2）没有将最新的代码信息综合进去；3）容易产生错误的逻辑；4）因为读错文件头而很容易产生类似"UnexpectedEndofFile"的错误。
两个编译器有个共同点是都能识别无用的"死"代码，比如一个没有用的函数等等。
编译后的程序将不包含这些多余的信息。
Delphi在这方面作得更加出色。
它可以让你在编辑器中可视化地提示出那行代码是"活"的、那行代码是"死"的。
这样你就能整理出最精简的代码。
Delphi在编译后将在左边显示一个小蓝点表示这行代码是"活"的。
VisualC++做不到这点。
Delphi编译后可执行文件至少有200K（如果不使用VCL，仅仅使用WinAPI，文件的大小将大大缩小）但是VisualC++编程使用MFC编译后的可执行文件通常只有几十K，主要是因为微软已经将系统运行库包含在Windows系统了（Borland公司曾经和微软协商这个接口，但是微软利用操作系统的优势不愿意公开）。
同样道理，使用BDE开发的的数据库程序必须附带3-5M的额外系统文件，也是非常不协调的。
非常有趣的是，Delphi能够使用由C++Builder创建的的OBJ文件，但是使用上受很大的局限性。
最后，VisualC++的编译和连接时的错误信息比Delphi要详细和具体的多。
特别是使用ATL开发更加如此。
应用框架：
MFC？
有KFC流行吗？
应用程序框架（ApplicationFrame），有时也称为对象框架。
VisualC++采用的框架是MFC。
MFC不仅仅是人们通常理解的一个类库（同样，Delphi的VCL也不仅仅是一个控件库，尽管它的名字叫"可视控件库"）。
你如果选择了MFC，也就选择了一种程序结构，一种编程风格。
MFC早在Windows3.x的时代就出现了，那时的VisualC++还是16位的。
经过这些年的不断补充和完善，MFC已经十分成熟。
但由于原型出现得比较早，MFC相比于VCL落后了一个时代。
尽管微软对MFC的更新没有停止，我也经常读到"只要Windows不过时，MFC就不会过时"之类观点的文章，但就象Inprise（原Borland）的OWL框架的淡出一样，MFC的淡出也是早晚的事。
其实MFC是和OWL同一个时代的产物。
OWL已经不在了，MFC怎能不"居安思危"呢？
如果MFC青春永驻，微软的开发人员也不会"私自"开发出基于ATL的WTL呀。
当然，WTL的地位不能和MFC比，它并不是微软官方支持的框架，封装的功能也相当有限。
但至少也反衬出了MFC存在的不足。
我们以为，最能体现一个应用程序框架的先进性的是它的委托模型，即对Windows消息的封装机制。
对WindowsAPI的封装就不用说了吧。
大同小异，也没什么技术含量。
如果高兴，你也可以自己写一个类库来封装。
但对Windows消息驱动机制的封装就不是那么容易的了。
最自然的封装方式是采用虚成员函数。
如果要响应某个消息就重载相应的虚函数。
但出乎我的意料，MFC采用的是"古老"的宏定义方法。
用宏定义方法的好处是省去了虚函数VTable的系统开销（由于Windows的消息种类很多，开销不算太小）。
不过带来的缺点就是映射不太直观。
对于MFC，则是"太不直观"了。
它的消息映射代码虽然是可见的，但"劝君莫碰"。
好在VC的ClassWizard可以自动生成消息映射代码，使用起来还算方便。
但和VCL的委托模型相比，MFC的映射方法就显得太落后了。
而Delphi的ObjectPascal因为没有"标准负担"，语言引入了组件、事件处理、属性等新特性。
由于功夫做在编译器级，生成的源代码就显得十分简洁。
似乎VC是"让框架迁就语言"，而Delphi是"让语言迁就框架"。
我想举一个对字符串操作的封装的例子来说明MFC和VCL的优缺点。
在MFC中，CStringList类有加入、获取、删除等功能，但VCL的TStringList类除了上述功能还有排序、从逗号分隔的字串读入、流输入输出等功能。
但同样的字符串替换功能，VCL的StringReplace要比MFC的CString:
:
Replace慢2－3倍。
总的来说，VCL的封装比MFC更为高层，更为抽象，但不可避免地带来的问题是某些部分执行效率比MFC略低。
这就象低级语言（如汇编）的执行效率比高级语言（如Basic）高，但编程效率较低。
鱼和熊掌不可兼得嘛。
VCL比之MFC的另一优点是对异常处理的支持，而一大缺点是对多线程支持差。
VCL的大部分都不是针对多线程优化的。
虽说VCL提供了简化多线程操作的类，但只是工作者线程（workerthreads）使用起来比较简单。
如果线程要和界面打交道的话事情就变得麻烦了，因为除了应用程序的主线程，任何线程不能访问任何可视的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的确不如VisualC++稳定，但也不至于如此呀。
我估计是那位朋友的Delphi装了某些有问题的第三方控件，导致了Delphi的频频出错。
不妨卸下那些控件试试？
可移植性：
立足现实，放眼未来
Inprise正在开发Delphi的Linux版本，代号为Kylix。
也许通过Kylix，用VCL构架编写的Windows程序向Linux移植成为可能。
但这只是可能。
因为在目前Inprise的兼容性工作做得并不好。
低版本的Delphi不能使用高版本的VCL组件，而高版本的Delphi竟然不能使用低版本的VCL组件。
真是岂有此理，我们很少看见软件有不向下二进制兼容的。
如果Windows98不能运行95的程序，Windows95不能运行3.x的程序，Win3.x不能运行DOS程序，你还会用Windows吗？
如果Windows95的程序必须经过重新编译才能在98下运行，98会卖得那么好吗？
"同门兄弟"C++Builder和Delphi也不能互相使用对方的组件，甚至同一套VCL库的文件名也不一样。
所以一个组件有forD1/D2/D3/D4/D5/C1/C3/C4/C5这些不同版本是常有的事，而且随着Delphi和C++Builder版本的升级可能还会增加。
希望Inprise能先解决同门兄弟的兼容性问题。
而微软的VC就没有这类问题。
MFC1.0的程序也可以毫无障碍地在VC6.0下编译通过。
集成界面：
宏观与微观
就大处说，VC的集成界面是不如Delphi的。
Delphi仅仅一个ObjectInspector就可以将VC的一堆Wizards比下去，何况它还有CodeExplorer、ToDoList等。
但从小处，又可以看出Delphi的不成熟。
比如"自动完成"功能的智能化程度和提示详细程度不如VC，响应速度也没有VC快。
VisualC++所带的MSDN是一部"开发者的百科全书"，信息庞大，查询方便，这方面比Delphi更专业。
很多帮助项都有源程序示范。
Delphi的OpenTools是完全面向第三方的开放系统，开发者可以修改很多Borland公司自身的功能，从IDE的可扩充性上说Delphi更好。
调试：
细微之处见真功
VisualC++和Delphi的调试功能都非常强大，同时都具有单步可视化调试、断点跟踪、运行时改变变量、鼠标指向可以得到变量值等等功能。
对DLL的输入输出也能方便的管理，能够进行源码级别的调试。
相对而言，VisualC++能够更加方便地看到变量的变化情况，这包括对结构可以展开成数据树，从而了解每一个变量的值，每一步调试，变化了的变量会加红，从而使调试更加方便。
另外，VisualC++的块内存察看比Delphi也要方便。
当然，Delphi也有很多体贴的细微之处，比如在线程调试的时候，Delphi能够很方便地察看线程的变化，VisualC++却必须要弹出一个模式对话框。
数据库开发：
Delphi一枝独秀
数据库支持是Delphi的强项。
这主要体现在Delphi与BDE的无缝集成，以及Delphi提供的那一大堆现成的数据库操作控件。
这是VC望尘莫及的。
目前Delphi支持BDE、ADO、InterBase三种数据库访问方式。
所有的方式都能拖拉到应用程序中实现可视化操作。
正是因为Delphi对数据库类的包装，使得用户操作数据库不像在VisualC++中必须从开始到最后都要干预。
明显地提高了开发速度。
Delphi中使用WebBroker控件还能很方便地构造出基于数据库的Web页面，通过HTML管理Web数据库。
VisualC++访问数据主要通过ADO和OLEDB，很多ActiveX控件也能添加数据库功能。
但是没有像Paradox这样的桌面数据库，Access相对功能太弱了。
也许SQLServer是不错的选择。
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（）等等。
VisualC++实现COM编程有一种特殊的方法就是使用ATL。
ATL使用VisualC++特有的多重继承来实现COM接口。
虽然不见得实现COM服务和控制更容易，但是ATL和最新COM技术的接口，基于模板的构造都比Delphi强。
ATL更有利于建立小巧、快捷的COM组件程序。
按目前通用的观点，VisualC++应用到COM服务程序更有优势，Delphi应用到COM组件程序更合适。
昨天，今天，明天
技术的进步在很多时候是此消彼长的。
当初Borland的TurboC和BorlandC++几乎是C/C++程序员唯一的选择。
微软的QuickC（现在还有人知道这个产品吗？
）和MicrosoftC/C++从来也没有成为过主流。
但BorlandC++又流行了多少年呢？
不久就被新崛起的MicrosoftVisualC/C++压下去了。
于是Inprise（原Borland）拣起了当年TurboPascal和BorlandPascal的辉煌（事实上Borland的成名作就是第一个Pascal编译器），全力推出了Delphi。
Delphi当初推出时被称为VB杀手，但VB现在仍然活得挺好。
毕竟微软是靠Basic起家的嘛，VB不是那么容易被打败的。
Inprise想了想不和VB争了，使用Delphi的IDE和VCL配上C++语言，推出了C++Builder，又向VisualC++的市场发起了夹攻。
C++Builder似乎是个不错的折衷选择了？
再仔细想想！
C++Builder的优点Delphi都有，但Delphi的优点C++Builder未必有。
比如C++Builder的编译速度比VC还慢，哪能和Delphi比？
而且因为VCL是ObjectPascal写的，C++语言和VCL磨合得并不好。
C++Builder的bug比Delphi还多，甚至Sample代码中还有错。
VCL的部分功能不能使用，要靠嵌入pascal代码访问。
C++Builder可用的第三方控件远没有Delphi多。
唉，真是金无足赤。
Microsoft和Inprise，谁会笑在最后呢？
鱼和熊掌：
艰难的选择
选择一个开发工具依赖于很多不同的因素，每个人都能因为某种语言的某个缺陷而放弃学习或使用这种语言。
任何程序员都希望自己喜欢的工具能达到理想的境界，通过上面不完善的比较，我想大家都有自己的看法。
我们认为影响大家选择开发语言的因素主要包括：
1）哪门语言更容易入门？
学习一种语言需要投入大量的时间和精力。
开发程序的开发成本是值得考虑的现实。
一个熟练的Delphi程序员和一个熟练的VC程序员工作效率是一样的。
但是，成为熟练的程序员必须很快掌握一门语言的技巧。
不幸的是，目前熟练的VisualC++程序员是十里挑一。
相对而言，Delphi更适合初学者。
2）哪门语言有更多可继承的代码？
语言代码的可重用性是加快开发效率明显方面，从早期的过程、函数到现在的组件技术都是朝这个目标在奋斗。
这两种语言对代码重用的理解是不一样的，Delphi主要通过VCL控件来实现代码重用，VisualC++实现起来就比较复杂。
3）语言自身的本性。
就技术（主要指应用框架）来说，Delphi目前领先于VisualC++。
但稳定性和健壮性的不足又让我对Inprise"想说爱你不容易"。
而VC尽管发展到今日已十分完善，但MFC框架已是明日黄花了。
如果不使用MFC，目前又没有合适的替代品。
根据你的需要和实际情况做选择吧。
实际上VisualC++和Delphi也不是简单竞争关系。
它们在许多领域并不重叠，甚至是互补的。
到底怎样取舍，要根据你的项目特性决定。
如果你开发系统底层的东西，需要极好的兼容性和稳定性，选VisualC++吧。
你可以只调用Windows的各种API，不用MFC。
如果你写传统的Windows桌面应用程序，VisualC++的MFC框架是"正统"的选择；如果界面部分占这个应用程序代码比例较大的话，或者Delphi中有相关功能的控件的话，Delphi是事半功倍的选择。
如果你为企业开发数据库、信息管理系统等高层应用（"高层"是相对于"低层/底层"而言的，不是说技术高级或低级），而且有比较紧的期限限制，选Delphi比较好。
如果你熟悉的语言是ObjectPascal，又不打算学复杂的C++，那么Delphi几乎是唯一的选择。
传统的观点是：
Delphi适合编写Internet/Intranet、表格制图、数据库操作、高级用户界面等等。
VisualC++适合编写设备驱动、COM服务程序、科学计算、控制台（console）程序、WinCE的应用和一些小的工具等等。
应用范围的不同要求好的程序员同时精通这两门语言。
4）语言的前景和可扩充性。
Delphi是Inprise的旗舰产品之一，前景应当还是比较乐观的，而且Inprise已经在向Linux进军了，而微软还迟迟没有动作。
遗憾的是，Inprise公司Delphi的创始人已经跳槽到微软去主持VisualJ++和C#项目了。
但愿对Inprise冲击不会太大。
微软的VisualC++的前景又怎样呢？
VisualStudio7.0就要推出了。
这一版本将加强网络开发的特性。
看来微软虽然被判解体，开发实力可是一点没打折扣。
另外，虽说MFC已稍显落后，但不是说它不值得学。
事实上，不学MFC就等于没学VC。
利用MFC框架开发程序仍然是目前开发桌面应用的主流模式，而且还会保持相当长的时间。
微软公司CEO史蒂夫·巴尔默（SteveBallmer）曾说，.NET流行还得等2－3年。
那么，MFC至少还有2－3年的生命空间。
在技术日新月异的IT界，2－3年实在是很长一段时间了。
好好把握吧。
即使你不使用MFC框架，花点时间看一下MFC的封装机制对你熟悉C++的OOP机制和Windows底层功能也是很有好处的。
而VCL的源代码是ObjectPascal的，对C/C++程序员就没有这个"额外"的作用了。
升级会员 