由于 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 的 www.hnxxlw.cn 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