MFC （微软）

    微软基础类库（英语：Microsoft Foundation Classes，简称MFC）是一个微软公司提供的类库（class libraries），以C++类的形式封装了Windows API，并且包含一个（也是微软产品的唯一一个）应用程序框架，以减少应用程序开发人员的工作量。其中包含的类包含大量Windows句柄封装类和很多Windows的内建控件和组件的封装类。

MFC,C++,VC++,VS2010 之间到底是什么关系

• C++是在C语言的基础上发展而来的面向对象的一种语言；

• MFC是基于C++类的窗体开发工具，内含大量的基类，减少编程人员的工作量；

• VC++是一种开发工具。

• VS2010是更高版本的开发工具，功能强大，内集合VC++，VB，C#等 。

特性

    Visual C++包含MFC应用程序向导，可用于兼容MFC的应用程序。在ATL程序中也可以手动添加MFC支持。在向导中有各种选项以定制生成的程序的功能，例如界面风格、语种、数据库开发支持、打印支持、自动化支持、ActiveX支持、网络支持、基于HTML的帮助文档支持等等。

    在COM开发方面，相对于ATL来说，MFC的组件比较大，代码不够短小精悍，但是支持的功能也比较多，例如有对ActiveX Document的封装类。

    在界面开发方面，MFC提供对消息循环的封装，使用消息映射来避免虚函数的开销。MFC也提供常用Windows通用控件的封装类。

MFC扩展DLL的接口使得MFC程序可以直接调用MFC扩展DLL中的MFC类。MFC也支持在标准DLL中被使用。

特性

    Visual C++包含MFC应用程序向导，可用于兼容MFC的应用程序。在ATL程序中也可以手动添加MFC支持。在向导中有各种选项以定制生成的程序的功能，例如界面风格、语种、数据库开发支持、打印支持、自动化支持、ActiveX支持、网络支持、基于HTML的帮助文档支持等等。

    在COM开发方面，相对于ATL来说，MFC的组件比较大，代码不够短小精悍，但是支持的功能也比较多，例如有对ActiveX Document的封装类。

    在界面开发方面，MFC提供对消息循环的封装，使用消息映射来避免虚函数的开销。MFC也提供常用Windows通用控件的封装类。

MFC扩展DLL的接口使得MFC程序可以直接调用MFC扩展DLL中的MFC类。MFC也支持在标准DLL中被使用。

发展

    MFC是在1992年随微软的Microsoft C/C++ 7.0编译器发布的，用于面向16位Windows的软件开发。起初，MFC是作为一个应用程序框架开发的，所以定名为Application Framework eXtensions（AFX）。

    随着Visual Basic和Visual Studio .NET的发布，曾经一度被微软重点推荐的MFC被Visual Basic .NET、C#、Windows Forms抢走了不少市场份额，但是MFC继续在非托管软件开发中占据重要地位。在托管开发方面，MFC中也包括对Windows Forms和托管/非托管互操作的封装。微软在Windows Vista和Windows 7发布之后在MFC中增加了对新的Windows API支持。 

MFC的优点

    MFC的主要优点是可以用面向对象的方法来调用Windows API，以及能够更加便捷地开发应用程序。MFC将很多应用程序开发中常用的功能自动化，并且提供了文档框架视图结构和活动文档这样的便于自定义的应用程序框架。同时，在Visual C++内部也内建了很多对MFC的例如类向导这样的支持以减少软件开发的时间，使用类向导可以快速生成Hello World程序。

MFC的缺点

    虽然MFC的源代码对用户是完全开放的，但是MFC的一些封装过程过于复杂，以致于新用户很难迅速掌握MFC的应用程序框架，以及在调试中定位问题的位置。同时，很多MFC对象不是线程安全的，致使在跨线程访问MFC对象时需要编写额外的代码。另外，MFC的很多类依赖于应用程序向导生成的代码，使得在使用Visual C++中其他类型的应用程序向导生成的工程中添加MFC支持的难度大大增加。 [2] 

第三方支持

    很多商用类库在MFC的基础上进一步实现了皮肤、渐变风格、多顶层窗口程序、属性列表等较受欢迎的功能；同时，在C++在线社区中，很大一部分开放的源代码也是基于MFC的。 

支持MFC的DLL开发编辑

使用Visual C++可以开发3种DLL：

不使用MFC的DLL；

使用MFC的规则的DLL：输出的函数不涉及MFC，因此可以被支持/不支持MFC的应用程序调用该DLL

动态链接到MFC（Regular DLLs statically linked to MFC）。

静态链接到MFC（Regular DLLs dynamically linked to MFC）

使用MFC的扩展DLL（Extension DLLs），只能动态链接到MFC：输出的函数涉及MFC，也可以输出基于MFC的派生类。

由于DLL与调用它的应用程序都可以有自己的MFC全局数据与句柄映射（handle mapping），如果句柄值相同，则默认使用应用程序的映射到的资源。为了不互相干扰，允许DLL内部使用自己的资源，必须在DLL函数的入口处把资源模块句柄从默认的应用程序切换为该DLL。办法是：

在该DLL的每个输出的函数的最开始之处调用AFX_MANAGE_STATE(AfxGetStaticModuleState( ))。函数AfxGetStaticModuleState的功能是在运行栈上创建一个AFX_MODULE_STATE类的实例，对其进行设置，函数返回值为AFX_MODULE_STATE的指针。AFX_MODULE_STATE类利用其构造函数和析构函数进行模块状态现场存储及恢复。

使用AfxGetResourceHandle();获取当前资源模块句柄。使用AfxSetResourceHandle(HINSTANCE xxx); 设置程序要使用的资源模块句柄。

什么人还需要关心一下MFC？

IT历史学家需要大写特写MFC曾经短暂的辉煌，考古学家需要考证这块化石的时候。

MFC就是微软一个框架类   跟QT、WTL基本就是同类产品

    唯一区别就是MFC没有维护，没有创新了，而QT挂着跨平台的称号（也就是外层统一API，如果linux则调用linux的API，微软的就调用微软的系统API）

    小白也好，大神也好。认为当前项目有必要使用MFC就用

你想让小白直接用系统API写代码，也可以啊，一个main函数，然后创建窗口，创建按钮等等等

我不知道你喷MFC有什么意义？你喷MFC，跟你喷QT有区别？QT我可以说，他就是另一个MFC，唯一就是跨平台

如果微软再升级一次MFC，封装一下linux的API跟windows的API，秒你QT分分钟

我入门的时候，就是看的MFC，因为MFC简单易懂，我不需要关心系统API，我只需要调用MFC的API就能实现我的功能

通过MFC，再去玩WTL、纯API开发，就简单多了，这是我的经历，我不知道其他人是什么情况。

但是你喷MFC是毫无意义的事情。。。

    我的题目是新手彻底放弃没落的MFC，并没有说MFC彻底没落，更不是说MFC一点用也没有。你说的很清楚，MFC毕竟是15年前的设计，它的定位就是局限在开发Windows 95内核上的客户端。既不能用于手机开发，又不能用于物联网。当然，还有应用服务器，Web服务器，数据库服务器就更不用说了。使用者越来越少不是很明显的趋势吗？所以我建议新手放弃MFC是没有问题的。

     编程语言，框架，工具等之研发团队就像武器之军队，原子弹的出现并没有淘汰掉冲锋枪，甚至古老的匕首也存在着不可替代的作用，这是武器的生存空间问题。如果从整个作战系统的全局来考虑每一类武器的生存空间，重骑兵，投石车，被淘汰也就在情理之中了。MFC就像投石车，即使发明它的企业也早就不做任何改进了，而远程投射系已经经历了大炮，火箭炮，进而向弹道导弹的方向推进，它未来的生存空间在哪里？

    某项技术好不好我这种菜鸟没发言权，但C#之类的东西运行慢是真的，能感觉得到，而且还得一大堆库的支持，烦得很。

QT也慢，不知道怎么回事。

    MFC胜在简单、通用、稳定，它还是有自己的市场的，一些偏硬件的公司通常用它做上位机软件（当然也有选择用C#的），这些软件完全不需要花哨的界面，只关注功能的实现，MFC是非常好的选择，需要的维护人员也少。

    无论MFC也好，WTL也好，WPF也好，QT也好，都是工具，各有自己的特点，谁熟练就用谁，不过，论学习成本，我还是觉得MFC是最容易掌握的

    Visual C++前面的那个Visual指的是可视化界面编程，是本质特点，而MFC就是界面编程的基础类库。界面编程就是MFC编程的主战场，逃离了界面战场它什么都不是。MFC的简单易用只是相对于Windows API的，因为它是对Windows API的封装，它的快只是相当于在没有飞机之前的时代，蒙古的骑兵的那种快。

    你在这展示的恰恰是MFC的局限性，当然这首先是GDI的局限性，花哨的界面都是靠贴图，切换图片。图片都是静态的，是死的，如果你用图片表示一个电池，还要设计多个图片表示电池的不同状态，比如说电量报警的情况。如果还要根据电量的数值来绘制电量的饱满程度，就只能用自定义控件了。界面设计师只能用PS来设计，设计出来程序员还不一定能开发出来。

另外，15年的发展，显卡已经从一个黄脸婆发展成一个亭亭玉立，芳龄二八的美少女了，而MFC从一个壮小伙子逐渐发展成82高龄的老翁。无论她有多少炫丽夺目的功能和性能，他已经再也驱动不了了，只能多买一此衣服让切换。如果说他们仍然深爱着对方，不得不说是思想层面的事了，哦，“思想”真是个好词，有什么事说不通，就可以说成是“思想“上的。

从未放弃过MFC

现在掌握两种语言：C#与MFC

个人认为两种各有特色，对同一个工程：

C#:开发周期短，UI及各类控件五花八门，简单易用

MFC:开发周期长，UI不好建立（虽然有bcg之类的），但效率比较高

目前没有放弃的原因，是现阶段主要进行视觉类程序开发，工业级方面的应用，效率非常重要，公司的一

个产品，进行视觉检测，C#执行120ms，C++下只要60-70ms

另外还是习惯MFC下的代码编写，C#里面写个跨线程，更新用户UI之类的，用委托，麻烦的要死

所谓MFC思想（一）

    好多人都强调学MFC关键是它的思想，好，我就把它从思想的火锅里捞上来，用手术刀剖开让大家看看它混乱的思想。从面向对象来看，界面类的内聚性很差，ID_，IDC_保存在Resource.h里，界面元素，布局等都保存在rc文件里，一个界面类的代码不能从根本上独立，这样所有的界面类自然而然的产生了耦合，这直接导致编码工作难以单元化，而这是根本性缺陷，必然给所有工作增加不必要的复杂度。比如集成工作要手工处理Resource.h，RC文件等，当然还有不同类库之间宏定义，WM_的冲突等等。比如配置管理工作，配置项识别就纠结不清，必然导致分支与合并额外的重复手工劳动，而手工劳动最容易引进新的错误。单元测试就更不用说了，MFC基本上处于软件开发的手工作坊阶段。这就是MFC过人的思想？不过，从另一个角度，MFC作为反面的教材有值得深思的地方。

    请问学会MFC都要学些什么呢？DOC-VIEW，OLE，UI线程，泵，钩，还是堆，栈内存分配与回收的机制？还是那些各种各样的CHAR，还是__cdecl， __stdcall，PASCAL等等，或者编译，链接的各种各样的参数？

继续讲故事，

MFC新婚之夜

    红烛高照，MFC美女偎依在VC程序员的怀里，娇羞不语，只见她身上只剩下最后一件罗衫了，上面印着两个斗大的字“思想”，她用手轻轻按住新郎的手，“爱到这一层就不能再往下了”，新郎不解“为什么呢?”

    他的目光似乎已经穿透罗衫，MFC压低了声音：“除非你发誓，一辈子只爱我一个，不能爱其它任何女人。“新郎略一思索，他也没见过其它美女呢，“我发誓，一辈子只爱你一个。”

    印着”思想“的那块布慢慢滑落，新郎顿时惊呆了，MFC分明就是一个透明人，五脏六腑一古脑的展现在新郎面前，扑哧扑哧跳动的心脏，缓缓蠕动的肠子。MFC急了，”我就说你别往下看了，你就不听，你还爱我吗？“VC程序员心想，又没见过别的美女，可能别的美女也都是这样的。赶紧说：”爱，爱，爱。“MFC有点诧异：“为什么？”新郎来不及多想，脱口而出：”这样我能学到更多的东西。“

    过了几年，丈母娘来了，沉思良久难以启齿，“这么说吧，当年我年轻的时候，邻居家有一个好闺女，我气不过跟别人家呕气，于是就生了MFC，没想到早产，天生有一些缺陷”。“什么？”VC程序员瞪大了眼睛“您不是一直声称，MFC是天下最好的美女吗？”丈母娘一见姑爷急了，马上说：“对对对，以前这么说没有错。不过我这几年又生了一个闺女，这一次才是最完美的。我现在想把这个闺女嫁给你，把MFC换回去。“ 

    VC程序员脸一下涨得通红：“给我什么也不换，我只要MFC。”

    “免费嫁给你也不要吗？不用买车买房，也不用聘礼。”

    ”我不希罕，我已经答应MFC，要爱她一辈子。”

    丈母娘有点无奈了，”我不知道你跟MFC发展到哪一步了，她的很多内部细节在不该暴露的时候都暴露了。“

    VC程序员显得很得意，”哈哈，我就喜欢她这样，这样我能学到更多的东西“。时间真是个魔鬼，几年的时间VC程序员已经完全习惯了MFC这种特殊的构造。

    丈母娘叹了口气，MFC这个闰女害得她受了不少骂，没想到还有这么爱MFC的，难道爱一个人真的就会爱她的全部，包括缺点？不过这种爱法太匪夷所思了，会不会是因为从来没见过别的Girl，误以为自己一直深爱着MFC呢？"你是不是从来没见过别的Girl呀？"

    “Girl？”VC程序员显得很不屑，"是CGirl好吗，有了MFC，我为什么还要去看别的CGirl？”

    丈母娘显然有些语无伦次了，”要不这样吧，把CMFC和她妹妹都嫁给你吧。时间长了你自己会作出正确的选择。“

    VC程序员：”算了吧，MFC才是我的最爱。对了，昨天我还跟您邻居家姑爷吵了一架，竟然敢鄙视MFC。”

    自己也算是个资深的MFC开发者了，越来越感觉MFC的没落，现在这两年也是渐渐远离MFC相关的开发项目，做点其他的。

楼主说的很对，建议新人不要深入学习了，不是MFC要被淘汰了，而是现在开发的主流趋势是多终端的，主要集中在移动端和服务端，所以只做桌面程序的市场是越来越小了。

    我从1997年使用MFC编程，到现在已经18年了，可是从来没觉得它落后了，关键是我这18年来只编写一个软件这个软件长度已经接近100万行C++代码了，里面自己建立数据库系统、自己建立编译器、自己建立人机界面开发平台等等，我现在用一个小时的时间开发的功能，估计你用C#、Java等语言一周都做不出来。

    我现在上班基本没人管，工资应该还行吧，每天就花一点时间编编程序，怎么编写程序自己定，怎么做都可以，你说MFC落后吗？关键是你采用MFC编写什么程序？比如：你给我编写一个桥梁载荷计算的程序，你是用什么编写好呢？要么你用MFC编写，或者你用MFC开发的平台软件ANSYS等来做，你还指望采用C#，Java能开发出来吗？？？？？

    MFC适合于开发复杂的二次应用平台，定位是比较高端的，简单点说，你如果要想开发一个类似EXCEL，浏览器等平台软件的程序，你这时候只能用MFC了，而且你编写完成后，你10年内都不容易落后！！！！！

    MFC诞生的时候是1992年，C++还没发明出命名空间，标准模版库也没有进入C++标准。

    从现代C++的眼光来看，MFC是丑陋的设计。被抛弃是必然的。

    说的有理。语言会影响思维方式。MFC还停留在史前C++时代。

    刚刚还有人在群里面发招聘信息 cocos2d 1年经验10k-15k，现在移动端薪水炒得是火热啊。

MFC呢？绝大多数都是维护历史系统吧，薪水能给到多少呢？

市场10多年前都转到Web了，现在更是向移动端转变。这些平台，别说mfc Win32的技术都用不上。

    越讨论越深入，但也越离题了。又回到了：语言只是工具，解决问题才是核心；语言都是相通的，精通一门语言后，学习其它的很快；.......

    标题主要是针对新手，这个很重要。现在依然有很多搞mfc拿着很高工资的人，也有很多搞mfc分分钟就转java、c#的人，也有很多没搞mfc，但随时可以上手的人，但这些人都不是新手。

对于新手要知道，mfc 是过时的，微软自家都不更新了；现在搞mfc的人很少了，工作需求也很少了；现在是移动、互联网、大数据、物联网的时代，那么多技术可以学习，没必要选一个过时的东西。

作为一个学过mfc的人，确实佩服楼主写那么多、回复那么多。跟楼主一样，劝新人，换一种技术学习。

    pc出货量持续下跌，手机终端已经成为人们连接互联网的最主要手段，传统pc上的应用越来越少，各种开发工具层出不穷。死抱着只能做微软的windows下的终端应用开发的mfc真的符合这个时代的发展要求么？

    如果你已经在mfc浸淫了数年，有所成就，不反对你继续使用。如果是新手还是绕道的好，不说开源阵营的qt，java等等可以选择，就是微软大一统的windows10对mfc的支持也是有限的。

与时俱进才是王道。