社区
非技术区
帖子详情
【我是菜鸟】VCL与MFC优劣大比拼,欢迎高手们高谈阔论
vcl007
2003-09-13 12:15:00
rt
...全文
440
14
打赏
收藏
【我是菜鸟】VCL与MFC优劣大比拼,欢迎高手们高谈阔论
rt
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
14 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
0123456789
2003-09-19
打赏
举报
回复
MFC是封装了WIN32API,从C编程转向了C++对象编程,加入了面向对象思想,但是由于一开始设计所致,MFC并不是面向组件,所以加入了ATL,WTL等面向组件开发的活动模板库,进行组件开发
VCL则是全部集成了两者,使用性方面强于MFC,但是在稳定性,可调试性方面弱于MFC
ly_liuyang
2003-09-13
打赏
举报
回复
VCL比MFC先进几个级别的
dmzn
2003-09-13
打赏
举报
回复
呵呵,其实,作程序重要的是编程思想,使用什么工具只是实现方法的不同而已,整个过程中,‘人’才是最终要的。所以各位还是炼好功夫,准备大展宏图吧。
roc_fu
2003-09-13
打赏
举报
回复
MFC感觉还不如用APIl列
FrameSniper
2003-09-13
打赏
举报
回复
什么类库归根结底都是对系统DLL的封装!我也认为没有什么可比性,各有其特点!
songandlan
2003-09-13
打赏
举报
回复
我喜歡vcl
沒什麼原因
CloneCenter
2003-09-13
打赏
举报
回复
没有可比性。
year2000bug
2003-09-13
打赏
举报
回复
(转)
经常看见有朋友在CSDN等论坛发帖子问Visual C++和C++Builder这两个重量级开发工具孰优孰劣(更多的是问Visual C++与Delphi孰优孰劣)。本文就试图从技术水平、易用性、稳定性、发展前景等对它们进行比较分析。
由于Delphi与C++Builder同为Inprise公司产品,共享集成开发界面(IDE),而且使用同一套VCL框架(这一点最关键),它们带的调试器、PVCS/TeamSource团队开发支持、数据库引擎及企业版中集成的其它高级功能等都是相同的,所以本文将其与C++Builder归入“同一阵线”。我在网上见到一些elphi程序员认为C++Builder与VC比较接近,这是个误解。事实上,Delphi和C++Builder除了使用的语言不同,其余几乎都相同。为了避免话题转移到C++语言与Object Pascal语言(即Delphi所用的语言)的比较,下文主要对比分析Visual C++与C++Builder。
首先,从它们的应用程序框架(Application Frame,有时也称为对象框架)进行比较。Visual C++采用的框架是MFC。MFC不仅仅是人们通常理解的一个类库。(同样,Delphi和C++Builder使用的VCL的概念也不仅仅是一个控件库。)你如果选择了MFC,也就选择了一种程序结构,一种编程风格。MFC早在Windows 3.x的时代就出现了,那时的Visual C++还是16位的。经过这些年的不断补充和完善,MFC已经十分成熟。但由于原型出现得比较早,MFC相比于VCL落后了一个时代。尽管微软对MFC的更新没有停止,我也经常读到持“只要Windows不过时,MFC就不会过时”之类观点的文章,但就象Inprise(原Borland)的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++Builder的兼容性好,实际上很大程度应归功于MFC的兼容性好。微软辛辛苦苦用标准方法写MFC,却为对手制造了方便。不知他们作何感想?而因为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先进的另一个特性是异常处理。但令人啼笑皆非的是,它的异常处理代码有bug,有时会无端抛出异常。不知道在最新的版本中有没有改正了。而VC的框架MFC也不是一无是处。经历了那么多年的发展和完善,MFC功能非常全面,而且十分稳定,bug很少。其中你可能遇到的bug更少。而且有第三方的专门工具帮助你避开这些bug。如此规模的一个类库,能做到这一点不容易。不要小看了这一点,很多专业程序员就是为这个选择VC的。而C++Builder的VCL的bug就相对较多了,而且有些它自己带的示例程序都有错误。看来Inprise还有很长的路要走。
再从它们的易用性比较。VC有ClassWizard、SourceBrowser等一系列工具,还附带Visual SourceSafe、Visual Modeler等强大的工具,易用性非常好。(VC自带建模工具Visual Modeler,也许说明了它才是工程级的开发平台,与C++Builder的定位不同。)它所带的MSDN这部“开发者的百科全书”更是让你“没有找不到的,只有想不到的”。而且它的AutoComplete之类小功能也比C++Builder要体贴。C++Builder的新版本虽然也提供了这一功能,但它的提示要等好几秒才出来,有时你不经意间把鼠标停在某一处,也要等硬盘响好几秒,这可是在566Mhz的赛扬II上呀。不要笑我琐碎,有时一个开发工具的成熟和易用,就是从这些小地方体现出来的。C++Builder作为RAD工具,理应强调易用性。但与VC相比还显出不成熟。这是不应该的。
再来看看它们的可移植性。Inprise正在开发C++Builder和Delphi的Linux版本,代号为Kylix。也许通过Kylix,用VCL构架编写的Windows程序向Linux移植成为可能。但这只是可能。因为在目前Inprise的兼容性工作做得并不好。C++Builder可以编译VC程序还要多谢微软使用标准方法写MFC,而它自己各个版本之间兼容性却不太好。低版本的C++Builder不能使用高版本的VCL组件(这还别去
说它),而高版本的C++Builder竟然不能使用低版本的VCL组件。真是岂有此理,我很少看见软件有不向下兼容的。如果Windows 98不能运行95的程序,Windows 95不能运行3.x的程序,Win 3.x不能运行DOS程序,你还会用Windows吗?如果不是C++Builder的其它某些方面太出色,光是这个向下不兼容就足以让我抛弃它。而且虽说通过捆绑编译器,C++Builder可以编译Delphi的Object Pascal代码,但C++Builder仍不能使用为Delphi开发的VCL组件。所以一个组件有for D1/D2/D3/D4/D5/C1/C3/C4/C5这些不同版本是常有的事,而且随着C++Builder版本的升级可能还会增加。希望Inprise能先解决同门兄弟的兼容性问题。而微软的VC就没有这类问题。MFC1.0的程序也可以毫无障碍地在VC6.0下编译通过。
再来看看它们的前景吧。实际上,技术的进步在很多时候是此消彼长的。当初Borland的Turbo C和Borland C++几乎是唯一的选择。微软的Quick C(现在还有知道这个产品吗?)和Microsoft C/C++从来也没有成为过主流。但Borland C++又流行了多少年呢?不久就被新崛起的Microsoft Visual C/C++压下去了。现在的C++Builder又有后来居上的态势,如果稳定性再提高一些,bug再少一些,有希望成为主流。但Inprise的总体实力不及微软,这也是无可争议的。从C++Builder5的Release Notes中的Known Issues部分,以及它们的帮助文档的规模和质量都可以看出。(哪个同类产品的帮助文档能和MSDN比呢?)Inprise公司应从Netscape吸取教训,不要让C++Builder成为第二个Netscape Communicator。(Communicator也是一度技术领先,甚至曾占据了大部分的浏览器市场,但似乎后劲不足,而且 6.0 PR1、2中bug多多,现在被IE压得抬不起头。)C++Builder是Inprise的旗舰产品之一,前景应当还是比较乐观的,而且Inprise已经在向Linux进军了,而微软还迟迟没有动作,难道非要到Linux成燎原之势(或许已经成燎原之势了)才会奋起占领这个新兴市场?似乎他们对Linux的态度与几年前对互联网的兴起的反应迟缓有些相似。但后来......唉,真希望Inprise不要步Netscape的后尘。C++Builder是一个很有前途的开发工具。遗憾的是,Inprise公司Delphi的
创始人已经跳槽到微软去主持Visual J++项目了。但愿对Inprise冲击不会太大。微软的Visual C++的前景又怎样呢?Visual Studio 7.0不久就要推出了。不知能不能在保持稳定性的同时在技术的先进性上赶上C++Builder。另外,这一版本将加强网络开发的特性。看来微软虽然被判解体,开发实力可是一点没打折扣。
就技术(主要指应用框架)来说,C++Builder目前领先于Visual C++。但多多少少的不尽人意之处让我对Inprise“想说爱你不容易”。而VC尽管发展到今日已十分完善,但MFC框架已是明日黄花了。如果不使用MFC,目前又没有合适的替代品。WFC是支持组件、属性和事件的,但那是Visual J++里边用的;ATL也很先进,但是用来进行COM/ActiveX开发的;基于ATL的WTL也不错,可惜是非官方作品,也未必比VCL先进。微软最近提出了C#(读作C Sharp)语言方案,但那属于和Java同一类的东西。看来是金无足赤啊。根据你的需要做选择吧。实际上Visual C++和C++Builder也不是单单竞争关系。它们在许多领域并不重叠,甚至是互补的。到底怎样取舍,要根据你的项目特性决定。如果你开发系统底层的东西,需要极好的兼容性和稳定性,选Visual C++吧。你可以只调用Windows的各种API,不用MFC。如果你写传统的Windows桌面应用程序,Visual C++的MFC框架是“正统”的选择。如果你为企业开发数据库、信息管理系统等高层应用(“高层”是相对于“低层/底层”而言的,不是说技术高级或低级。)而且有比较紧的期限限制,选C++Builder比较好。如果你用的语言是Object Pascal,Delphi是唯一的选择(如果GNU Pascal等免费编译器不考虑的话)。如果你原先用Delphi(Object Pascal语言),现在想改学C++,应当先用C++Builder。熟悉的界面和相同的框架会让你的转轨事半功倍。
另外,虽说MFC已显落后,但不是说它不值得学。事实上,不学MFC就等于没学VC。利用MFC框架开发程序仍然是目前开发桌面应用的主流模式,而且还会保持相当长的时间。即使你不使用MFC框架,花点时间学习一下MFC的封装机制对你熟悉C++的OOP机制和Windows底层功能也是很有好处的。
Eastunfail
2003-09-13
打赏
举报
回复
MFC比VCL稳定N倍,但是入门需要一定Windows程序设计的基础和C++的基础以及对MFC的研究。而VCL的“入门”就相对简单的多,不过VCL的Bug多多。
由于VCL的动态库很大,而且Windows的安装程序没有自带(MFC的动态库自带了),所以Delphi写出的程序总是很大(除非你用动态VCL库),这个也是MFC的一个优势。
windindance
2003-09-13
打赏
举报
回复
只是打个比方,呵呵,MFC也是90 年代才有的
windindance
2003-09-13
打赏
举报
回复
MFC:80年代的经典
VCL:90年代的经典
21世纪的经典:??
jaexc
2003-09-13
打赏
举报
回复
这怎么能比较呢?
还有这是Delphi的版快,所以呢不好公证的看待着个问题 !
ghostmirror
2003-09-13
打赏
举报
回复
-_-讨论这些东西有什么意义么?
哪个好用,哪个方便就用哪个~~~
这种题目就是个水坑
hkbarton
2003-09-13
打赏
举报
回复
VCL是完全采用OO的方法来设计的,MFC?不清楚了,但VCL应该封装成都要高些吧。不过同意fs和复制中心,各有各的优点
DevExpress
VCL
V14.2.2 FullSource〖D7~XE7〗含编译文件
解压后XE7有编译文件,其他版本需要修改编译文件,请阅读说明文档; 另附一键安装工具下载地址(CSDN下载0积分、不要积分): http://download.csdn.net/detail/wozengcong/8395245 另附14.2.2帮助文档下载地址(CSDN下载0积分、不要积分): http://download.csdn.net/detail/wozengcong/8395133 拥有180多种
VCL
界面控件,功能丰富且易于上手 DevExpress
VCL
Subscription 是 Devexpress公司旗下用户界面产品套包,包含该公司所有
VCL
控件产品和 ASP.NET控件产品以及相关产品的完整源码。所包含的控件有:数据录入,图表,数据分析,导航,布局,网格,日程管理,样式,打印和工作流等,让您快速开发出完美、强大的
VCL
应用程序!DevExpress
VCL
Subscription曾用名为"Developer Express
VCL
Subscription"。 【适用范围】:
VCL
应用程序开发
VCL
比
MFC
好在哪里
作者:刘国华 链接:https://www.zhihu.com/question/35218485/answer/118472021 来源:知乎 著作权归作者所有,转载请联系作者获得授权。 从使用感受而言,
VCL
甩
MFC
不知道多少条街,
VCL
虽然是基于Pascal实现的,然后C++Builder又在上面套了一层C++的壳,但是对于使用C++的人来说,已经非常好用了。记得当时(2002年
由
VCL
和
MFC
想到的 …
由
VCL
和
MFC
想到的 …最近在猛看
MFC
,发现不知
MFC
的封装是为了什么?我们使用面向对象的方法,应该是为了使编程更简单,需要更少的计算机知识,使程序更容易理解。换句话说,让计算机理解我们的想法;而不是让我们越来越繁杂的概念和各种所谓的“设计模式”。如果有一天我们对计算机说,我需要针对双处理器的机器写一个图像处理程序,它就生成了一个程序。或者说,我们告诉机器第一步做什么,第二步做什么,它就能做出
MFC
?
VCL
?
网上争论VC和DELPHI/BCB
优劣
的朋友甚多(其实不是最近,一直都很多),其实真正有分歧的多半在
MFC
和
VCL
两套类库的选择上。不知道诸位对这两套类库,或者说是Application Framework(下面简称AF)的理解究竟如何? 对于一套AF,跟一套类库class library最大的不同,在于它是一套完整的已经构建好的框架,风格、结构都已经做好,你不得不去遵守,而类库讲
如何在 C++ Builder 3.0 下混用两大 Application Framework
VCL
&
MFC
?
如何在 C++ Builder 3.0 下混用两大 Application Framework
VCL
&
MFC
? 混用
VCL
与
MFC
的确是个不错的选择,但是、相对的,你的程序复杂度反而会提高。 在此先假设你已经看过『如何在 C++ Builder 3.0下编译含有
MFC
的程序』这一篇文章了。因此一
非技术区
828
社区成员
53,611
社区内容
发帖
与我相关
我的任务
非技术区
Delphi 非技术区
复制链接
扫一扫
分享
社区描述
Delphi 非技术区
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章