评价网 > 科教论文 > 工学毕业论文 > 计算机应用论文 > 正文

VisualC 与Delphi/C Builder之比较及未来的发展前景之

2015-01-28 01:18 由于Delphi与C Builder同为Inprise公司产品，共享集成开发界面(IDE)，而且
使用同一套VCL框架(这一点最关键)，它们带的调试器、PVCS/TeamSource团队开发支持
、数据库引擎及 企业 版中集成的其它高级功能等都是相同的，所以本文将其与C Build
er归入"同一阵线"。我在网上见到一些Delphi程序员认为C Builder与VC比较接近，
这是个误解。事实上，Delphi和C Builder除了使用的语言不同，其余几乎都相同。为
了避免话题转移到C 语言与Object Pascal语言(即Delphi所用的语言)的比较，下文主
要对比 分析 Visual C 与C Builder。


　　首先，从它们的 应用 程序框架(Application Frame，有时也称为对象框架)进行比
较。Visual C 采用的框架是MFC。MFC不仅仅是人们通常理解的一个类库。(同样，Del
phi和C Builder使用的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的映射方法就显得太落
后了。而C Builder对C 语言进行了扩展，以便引入组件、事件处理、属性等新特性。
由于功夫做在编译器级，生成的源代码就显得十分简洁。但是由于扩展的非标准特性，
使用VCL的C Builder的源代码无法被其它编译器编译。而MFC的功夫做在源代码级，虽
然消息映射代码较为复杂且不直观，但兼容性非常好。只要你有MFC库的源代码(随VC企
业版的光盘提供)，你的MFC程序 理论 上用任何符合ANSI标准的编译器均可编译通过。C
Builder 3以上版本可以原封不动直接编译Visual C 程序，很多人认为这是C Build
er的兼容性好，实际上很大程度应归功于MFC的兼容性好。微软辛辛苦苦用标准方法写M
FC，却为对手制造了方便。不知他们作何感想？而因为C Builder对语言作了扩展，VC
不能编译C Builder的程序。看来在这方面VC要输给C Builder了。而且VCL所支持的组
件、属性等都是MFC所缺乏的特性。虽然VC也能支持组件，但要通过AppWizard先生成一
个"包裹"类(wrapper)，不如VCL来得简洁。有很多人使用C Builder就是冲着控件板
上那一大堆组件来的，VC虽然能使用的组件也很多(也许不比C Builder少)，但由于不
方便而对RAD程序员没有吸引力。


　　C Builder的VCL比Visual C 的MFC先进的另一个特性是异常处理。但令人啼笑