我从未成为MFC的忠实粉丝，但这并非如此。我读到微软将于2010年发布一个新版本的MFC，这真让我感到奇怪 - 我认为MFC已经死了（没有恶意，我真的这么做了。）
MFC是否用于新开发？如果是这样，那么好处是什么？我无法想象它对诸如C＃之类的东西有任何好处（或者甚至只是使用Win32 API的c ++）。
答案 0 :(得分：24)
使用MFC有很多代码。我一直看到这些问题仍然使用的是仍然使用的答案是肯定的。我在一个非常庞大的组织工作，仍然雇佣了数百名用cobol写作的人。如果曾经在企业中使用它，它将继续被使用，直到没有更多硬件来支持它，然后一些公司将付钱给某人编写模拟器，以便旧代码仍然可以工作。
海军仍然使用带有磁芯计算机的船只进行记忆，我相信他们有人可以使用它们。创建的技术永远不会得到支持。它是Deus ex machina的一个例子，大型组织并不完全确定他们的系统是做什么的，并且拥有如此无所畏惧的企业畏缩的恐惧感，他们不想尝试新的技术（BTW）我们向IBM支付OS2上的尽力支持。
同样，mfc是一个完全可以接受的Windows开发解决方案，因为它是一个包装System API的对象模型，这几乎是大多数人从.net中获得的。
作为附录，由于这个问题是为了赏金，这是MS关于VS 11中mfc的引用
在每个版本中，我们都需要平衡我们在产品各个领域的投资。但是，我们仍然认为MFC是用于构建本机桌面应用程序的功能最全面的库。我们完全致力于以高质量支持和维护MFC。以下是我们在MFC for Visual Studio 11中修复的一些问题的简短列表：
如果你想阅读完整的帖子
，这是link答案 1 :(得分：18)
冷却不会影响为新系统选择技术。是的，如果你是一名学生或想要在你身边玩耍，你可以随意选择。
但在现实世界中，每种技术都有优点和缺点。一年前，其中一个团队开始了一个新项目，决定它将在MFC中完成。 原因很简单：他们必须使用windows api进行低级操作，打印机，Internet Explorer和上帝知道还有什么。
C＃甚至没有在游戏中，MFC和QT之间做出了决定，两者都有所需的功能，两者都可以轻松集成低级功能，唯一的区别是一些团队成员已经拥有MFC经验，所以他们没有浪费时间和金钱进行培训。
让我们假设他们选择C＃和WPF：
-1您必须将所有本机C ++和ASM代码包装在DLL中（哎呀，这可能很痛苦，而不是编写包装器的代码）。
-1你现在可能需要两支球队，一支是ui支持winapi的球队。你不太可能发现很多人都能写出C＃和winapi的东西。同意无论哪种方式你需要有人使界面漂亮（程序员通常很尴尬，他们花费更多）但至少只使用C ++代码，两个团队之间没有更多的等待时间，需要ui修改，没问题我不不得不等待ui设计师，他会很晚才这样做。
+1您可以在C＃和WPF中编写UI代码，假设UI开发速度更快，但UI只是项目的1/4，因此总增益可能非常小。
-1性能下降：对于您在C＃中无法执行的每个小操作，您调用外部DLL（这是一个小问题，因为程序在8GB RAM四核上运行）。
总而言之：MFC仍然用于新开发，因为需求和成本决定了项目的技术，而MFC在某些情况下是最好的。
答案 2 :(得分：14)
MFC仍然用于一些新的开发，以及大量的维护开发（包括微软内部）。
虽然它可能比直接使用Win32 API慢得多，但性能损失确实很小 - 很少会达到整整百分比。使用.NET，性能损失相当更大（在我的测试中，很少低于10％，典型的是20-30％，而且对于繁重的计算仍然更高。例如，我有一个在相当大的数组上进行特征向量/特征值计算的程序。我的原始版本使用C ++和MFC在我们的标准测试机器上在一分钟内在 中运行一个测试用例。我的一些同事认为它很酷在C＃中重新实现它。它们的版本在同一台机器上花了将近三分钟（四核，16 GB的RAM，所以没有，不是“传统”硬件）。我承认我没有查看他们的代码太密切了，所以也许可以改进，但是他们是不错的程序员，所以3：1的改进让我觉得不太可能。
使用MFC时，如果需要，也可以轻松绕过框架并直接使用Win32 API。使用.NET，可以使用P / Invoke，但相比之下它相当很痛苦。
答案 3 :(得分：8)
MFC已针对Visual Studio的每个版本进行了更新。它不是标题功能项。
至于新的发展，是的。它仍在使用，并将继续如此（即使我，像你一样，不愿意）。许多组织在几年前做出了技术决策，没有理由改变。
我确实认为你们正在谈论成熟的商店，人们更有兴趣保持/提高所写的内容而不是保持在最前沿。
答案 4 :(得分：8)
MFC Feature Pack（一年或两年前，iirc）的发布是MFC自10年以来的最大延伸，它为MFC的发展带来了新的推动力。我想很多公司都决定维护他们的遗留应用程序，推动他们前进，并在此基础上删除新的应用程序。
对我来说（作为必须维护大型MFC应用程序的人），更大的问题是（微软和第三方）组件的开发和支持的减少，而不是MFC本身。例如，如果在应用程序中组装了许多旧的和不支持的纯32位Active-X组件，则移植到64位并不容易。
答案 5 :(得分：3)
远离托管代码（可能是编写驱动程序UI或执行COM）有一些优点。
那里和那里有吨的MFC代码。也许你在X公司工作，并且需要使用他们在过去十几年里写过的众多DLL中的一个。
答案 6 :(得分：2)
我去年根据MFC做了一个项目。我不确定为什么选择MFC，但它足以构建一个虚拟3D图形用户界面 - 一个建筑管理安全系统 - 在基于win32的PC上可以高效运行每秒10帧的刷新率，可追溯到20世纪90年代中期。可执行文件（仅需要核心win32系统DLL）不到400K - 使用现代工具不是一件容易的事。
答案 7 :(得分：1)
我可以想到一个从使用 MFC 而不是 C# 中受益的商业软件名称：Wwise[1]。 C++ 是声音引擎的明显选择，因此用 C++ 编写创作工具也是有意义的。它既是创作工具又是声音引擎。他们本可以使用 C# 构建创作工具，并使用 C++ 构建声音引擎，但是如果他们正在调试声音引擎的问题，而该问题可通过 wwise 创作工具重现，那么他们更容易看到整个调用堆栈，就像这样.
我认为现在有一些方法可以实现混合调用堆栈，但也许在他们第一次制作 Wwise 时还没有这种方法？无论如何，使用 MFC 确保他们不需要解决混合调用堆栈问题。调用堆栈正常工作。
[1]Wwise 基于 MFC：https://www.audiokinetic.com/fr/library/edge/?source=SDK&id=plugin_frontend_windows.html