4个回答
展开全部
每个人可能都有自己的理由,我接触MFC也有很多年了,说下自己感受吧。
10多年前,MFC是windows平台上GUI编程框架的王者。MFC 4.2和VC 6是当年的黄金组合,彻底打趴了Borland公司。一是因为那个时候MFC是为数不多的比较完善的GUI框架之一,二是因为MFC可以说就是为WIN 95/98量身定做的,很完美地支持当时看起来还很新的功能,比如DPI等。
后来嘛,VC从6.0版发展到了Visual C++ 2008,操作系统从win 98变成了Vista,而MFC虽然版本号一直在更新,但实质一直没有大的变化,许多新功能都不支持,比如Ribbon。
再后来,微软发布了Visual Studio 2008 SP1(就是Visual studio 2008的补丁包),引进了许多新功能比如Ribbon,标签式的MDI,可定制的dock窗口等,但是!这些代码不是微软自己写的!是微软从BCG Soft买的!而这些代码的质量明显不如之前微软自己的代码。我自己就发现了不止一个bug。。并且似乎微软并没有投入多少精力来解决这些bug。所以现在要写窗口程序,MFC肯定不会是我的第一选择。
10多年前,MFC是windows平台上GUI编程框架的王者。MFC 4.2和VC 6是当年的黄金组合,彻底打趴了Borland公司。一是因为那个时候MFC是为数不多的比较完善的GUI框架之一,二是因为MFC可以说就是为WIN 95/98量身定做的,很完美地支持当时看起来还很新的功能,比如DPI等。
后来嘛,VC从6.0版发展到了Visual C++ 2008,操作系统从win 98变成了Vista,而MFC虽然版本号一直在更新,但实质一直没有大的变化,许多新功能都不支持,比如Ribbon。
再后来,微软发布了Visual Studio 2008 SP1(就是Visual studio 2008的补丁包),引进了许多新功能比如Ribbon,标签式的MDI,可定制的dock窗口等,但是!这些代码不是微软自己写的!是微软从BCG Soft买的!而这些代码的质量明显不如之前微软自己的代码。我自己就发现了不止一个bug。。并且似乎微软并没有投入多少精力来解决这些bug。所以现在要写窗口程序,MFC肯定不会是我的第一选择。
展开全部
若用C++做界面 MFC几乎是必须要掌握的 不然你就要同时会其他语言 但若不考虑界面 那就抛弃mfc
不主张用MFC的人基本都是不做界面的吧 不做界面 网络,驱动什么的你用MFC去做没效率 而且因为MFC是封装地层的一个库 过度依赖MFC会让自己不了解地层 让自己得不到进步 这才是很多人不主张用MFC的原因
不主张用MFC的人基本都是不做界面的吧 不做界面 网络,驱动什么的你用MFC去做没效率 而且因为MFC是封装地层的一个库 过度依赖MFC会让自己不了解地层 让自己得不到进步 这才是很多人不主张用MFC的原因
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
MFC架构不合理,学习使用难度很大,即便是多年开发人员,还是不得不经常查看MSDN来确定一些很基本的函数,例如清空内容控件的函数:RemoveAll,DeleteAllItems,ResetContent,这一点实在让人困惑,还有比如获取文本的函数:GetWindowText,GetLBText,也是乱起八糟。
架构不合理,例如CListCtrl或者CTreeView没有采用MVC模式,竟然直接要吧数据写入到控件里,实在匪夷所思。
其他方面,LS两人都提到了,M$自己都块要放弃MFC了,不表。
架构不合理,例如CListCtrl或者CTreeView没有采用MVC模式,竟然直接要吧数据写入到控件里,实在匪夷所思。
其他方面,LS两人都提到了,M$自己都块要放弃MFC了,不表。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
1L经验丰富,貌似有道理。
mfc那一套,开发难度大,周期长,维护难度大,虽然功能强大。
总结下,就是MFC微软自己都块要放弃了,微软现在主打.net框架,托管代码。
mfc那一套,开发难度大,周期长,维护难度大,虽然功能强大。
总结下,就是MFC微软自己都块要放弃了,微软现在主打.net框架,托管代码。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询