编译器级,生成的
源代码就显得十分简洁。似乎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等。但从小