【asp精品源码栏目提醒】:网学会员为广大网友收集整理了,【范文精品】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的。
而CBuilder的VCL的bug就相对较多了而且 有些它自己带的示例程序都有错误。
看来Inprise还有很长的路要走。
再从它们的易用性比较。
VC有ClassWizard、SourceBrowser等一系列工具还附 带Visual SourceSafe、Visual Modeler等强大的工具易用性非常好。
VC自带建模工 具Visual Modeler也许说明了它才是工程级的开发平台与CBuilder的定位不同。
它所带的MSDN这部开发者的百科全书更是让你没有找不到的只有想不到的。
而且它的AutoComplete之类小功能也比CBuilder要体贴。
CBuilder的新版本虽然也 提供了这一功能但它的提示要等好几秒才出来有时你不经意间把鼠标停在某一处 也要等硬盘响好几秒这可是在566Mhz的赛扬II上呀。
不要笑我琐碎有时一个开发工 具的成熟和易用就是从这些小地方体现出来的。
CBuilder作为RAD工具理应强调易 用性。
但与VC相比还显出不成熟。
这是不应该的。
再来看看它们的可移植性。
Inprise正在开发CBuilder和Delphi的Linux版本 代号为Kylix。
也许通过Kylix用VCL构架编写的Windows程序向Linux移植成为可能。
但 这只是可能。
因为在目前Inprise的兼容性工作做得并不好。
CBuilder可以编译VC程序 还要多谢微软使用标准方法写MFC而它自己各个版本之间兼容性却不太好。
低版本的C Builder不能使用高版本的VCL组件这还别去说它而高版本的CBuilder竟然不能 使用低版本的VCL组件。
真是岂有此理我很少看见软件有不向下兼容的。
如果Windows 98不能运行95的程序Windows 95不能运行3.x的程序Win 3.x不能运行DOS程序你 还会用Windows吗如果不是CBuilder的其它某些方面太出色光是这个向下不兼容就 足以让我抛弃它。
而且虽说通过捆绑编译器CBuilder可以编译Delphi的Object Pas cal代码但CBuilder仍不能使用为Delphi开发的VCL组件。
所以一个组件有for D1/D 2/D3/D4/D5/C1/C3/C4/C5这些不同版本是常有的事而且随着CBuilder版本的升级可 能还会增加。
希望Inprise能先解决同门兄弟的兼容性问题。
而微软的VC就没有这类问题 。
MFC1.0的程序也可以毫无障碍地在VC6.0下编译通过。
再来看看它们的前景吧。
实际上技术的进步在很多时候是此消彼长的。
当初Bo rland的Turbo C和Borland C几乎是唯一的选择。
微软的Quick C现在还有人知道这个 产品吗和Microsoft C/C从来也没有成为过主流。
但Borland C又流行了多少年呢 不久就被新崛起的Microsoft Visual C/C压下去了。
现在的CBuilder又有后来居 上的态势如果稳定性再提高一些bug再少一些有希望成为主流。
但Inprise的总体 实力不及微软这也是无可争议的。
从CBuilder 5的Release Notes中的Known Issue s部分以及它们的帮助文档的规模和质量都可以看出。
哪个同类产品的帮助文档能和 MSDN比呢Inprise公司应从Netscape吸取教训不要让CBuilder成为第二个Netsca pe Communicator。
Communicator也是一度技术领先甚至曾占据了大部分的浏览器市 场但似乎后劲不足而且 6.0 PR1、2中bug多多现在被IE压得抬不起头。
CBuil der是Inprise的旗舰产品之一前景应当还是比较乐观的而且Inprise已经在向Linux 进军了而微软还迟迟没有动作难道非要到Linux成燎原之势或许已经成燎原之势了 才会奋起占领这个新兴市场似乎他们对Linux的态度与几年前对互联网的兴起的反应 迟缓有些相似。
但后来 ......唉真希望Inprise不要
上一篇:
根据身份证号码求性别
下一篇:
那些令你为之触动的好句子,感慨万分