【vb精品源码栏目提醒】:网学会员在vb精品源码频道为大家收集整理了“【范文精品】Visual C++与Delphi-C++Builder之比较及未来的发展前景之我见 - 培训资料“提供大家参考,希望对大家有所帮助!
Visual C与Delphi/CBuilder之比较及未来的发展前景之我见 由于Delphi与CBuilder同为Inprise公司产品共享集成开发界面IDE而且 使用同一套VCL框架这一点最关键它们带的调试器、PVCS/TeamSource团队开发支持 、数据库引擎及企业版中集成的其它高级功能等都是相同的所以本文将其与CBuild er归入同一阵线。
我在网上见到一些Delphi程序员认为CBuilder与VC比较接近 这是个误解。
事实上Delphi和CBuilder除了使用的语言不同其余几乎都相同。
为 了避免话题转移到C语言与Object Pascal语言即Delphi所用的语言的比较下文主 要对比分析Visual C与CBuilder。
首先从它们的应用程序框架Application Frame有时也称为对象框架进行比 较。
Visual C采用的框架是MFC。
MFC不仅仅是人们通常理解的一个类库。
同样Del phi和CBuilder使用的VCL的概念也不仅仅是一个控件库。
你如果选择了MFC也就选 择了一种程序结构一种编程风格。
MFC早在Windows 3.x的时代就出现了那时的Visu al C还是16位的。
经过这些年的不断补充和完善MFC已经十分成熟。
但由于原型出现 得比较早MFC相比于VCL落后了一个时代。
尽管微软对MFC的更新没有停止我也经常读 到持只要Windows不过时MFC就不会过时之类观点的文章但就象Inprise原Borl and的OWL框架的淡出一样MFC的淡出也是早晚的事。
如果MFC青春永驻微软的开发人 员也不会私自开发出基于ATL的WTL呀。
当然WTL的地位不能和MFC比它并不是微 软官方支持的框架封装的功能也相当有限。
但至少也反衬出了MFC存在的不足。
我以为最能体现一个应用程序框架的先进性的是它的委托模型即对Windows消 息的封装机制。
对Windows API的封装就不用说了吧。
大同小异也没什么技术含量。
如果高兴你也可以自己写一个类库来封装。
但对Windows消息驱动机制的封装就不是那 么容易的了。
最自然的封装方式是采用虚成员函数。
如果要响应某个消息就重载相应的 虚函数。
但出乎我的意料MFC采用的是古老的宏定义方法。
用宏定义方法的好处是 省去了虚函数VTable的系统开销。
由于Windows的消息种类很多开销不算太小。
不过 带来的缺点就是映射不太直观。
好在较新版本VC带的ClassWizard可以自动生成消息映射 代码使用起来还是比较方便的。
但和VCL的委托模型相比MFC的映射方法就显得太落 后了。
而CBuilder对C语言进行了扩展以便引入组件、事件处理、属性等新特性。
由于功夫做在编译器级生成的源代码就显得十分简洁。
但是由于扩展的非标准特性 使用VCL的CBuilder的源代码无法被其它编译器编译。
而MFC的功夫做在源代码级虽 然消息映射代码较为复杂且不直观但兼容性非常好。
只要你有MFC库的源代码随VC企 业版的光盘提供你的MFC程序理论上用任何符合ANSI标准的编译器均可编译通过。
C Builder 3以上版本可以原封不动直接编译Visual C程序很多人认为这是CBuild er的兼容性好实际上很大程度应归功于MFC的兼容性好。
微软辛辛苦苦用标准方法写M FC却为对手制造了方便。
不知他们作何感想而因为CBuilder对语言作了扩展VC 不能编译CBuilder的程序。
看来在这方面VC要输给CBuilder了。
而且VCL所支持的组 件、属性等都是MFC所缺乏的特性。
虽然VC也能支持组件但要通过AppWizard先生成一 个包裹类wrapper不如VCL来得简洁。
有很多人使用CBuilder就是冲着控件板 上那一大堆组件来的VC虽然能使用的组件也很多也许不比CBuilder少但由于不 方便而对RAD程序员没有吸引力。
CBuilder的VCL比Visual C的MFC先进的另一个特性是异常处理。
但令人啼笑 皆非的是它的异常处理代码有bug有时会无端抛出异常。
不知道在最新的版本中有没 有改正了。
而VC的框架MFC也不是一无是处。
经历了那么多年的发展和完善MFC功能非 常全面而且十分稳定bug很少。
其中你可能遇到的bug更少。
而且有第三方的专门工 具帮助你避开这些bug。
如此规模的一个类库能做到这一点不容易。
不要小看了这一点 很多专业程序员就是为这个选择VC的