I've never been a big fan of MFC, but that's not really the point. I read that Microsoft is due to release a new version of MFC in 2010 and it really struck me as odd - I thought MFC was dead (no ill intention, I really did).
Is is MFC used for new developments? If so, whats the benefit? I couldn't imagine it having any benefit over something such as C# (or even just c++ using Win32 APIs for that matter).
有大量使用 MFC 的代码。我一直看到这些问题是这个还在使用吗？答案是肯定的。我在一个非常大的组织工作，该组织仍然雇用数百名用 cobol 写作的人。如果它曾经在企业中使用过，它将继续使用，直到没有更多的硬件支持它，然后一些公司会花钱请人写一个模拟器，以便旧代码仍然可以工作。
海军仍然使用带有磁芯的计算机来存储内存，我相信他们会有人在上面工作。技术一旦被创造出来，就永远无法得到支持。这有点像 Deus ex machina 的情况，大型组织并不完全确定他们的系统在做什么，并且有一种压倒一切的恐惧感，害怕让企业屈服，他们不想尝试新奇的技术（顺便说一句我们向 IBM 支付对 OS2 的最大努力支持）。
此外，mfc 是一个完全可以接受的 Windows 开发解决方案，因为它是一个包含系统 API 的对象模型，这几乎是大多数人从 .net 中获得的所有内容。
作为附录，由于这个问题需要悬赏，这是 MS 关于 VS 11 中 mfc 的引用
在每个版本中，我们都需要平衡产品各个领域的投资。但是，我们仍然认为 MFC 是用于构建原生桌面应用程序的功能最全的库。我们完全致力于以高质量支持和维护 MFC。以下是我们在 MFC for Visual Studio 11 中修复的一些问题的简短列表：
如果您想阅读完整的帖子，这里是链接
冷却度不是为新系统选择技术的因素。是的，如果您是学生或想四处玩耍，您可以选择您想要的任何东西。
但在现实世界中，每种技术都有优点和缺点。一年前，其中一个团队开始了一个新项目，决定在 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 在某些情况下是最好的。
MFC 仍然用于一些新的开发，以及大量的维护开发（包括微软内部）。
虽然它可能比直接使用 Win32 API稍微慢一点，但性能损失确实很小——很少达到整个百分比。使用 .NET，性能损失要大得多（在我的测试中，很少低于 10%，典型的是 20-30%，对于繁重的计算仍然更高。例如，我有一个执行特征向量/特征值计算的程序在相当大的数组上。我使用 C++ 和 MFC 的原始版本在我们的标准测试机器上运行一个测试用例不到一分钟。我的一些同事认为用 C# 重新实现它会很酷。他们的版本需要将近三分钟在同一台机器上（四核，16 GB RAM，所以不，不是“传统”硬件）。我承认我没有仔细研究过他们的代码，也许它可以改进，但他们是体面的编码人员，所以 3:1 的改进让我觉得不太可能。
使用 MFC，也可以轻松绕过框架并在需要时直接使用 Win32 API。使用 .NET，您可以为此使用 P/Invoke，但相比之下它相当痛苦。
MFC 已随 Visual Studio 的每个版本更新。它只是不是标题功能项目。
至于新的发展，是的。它仍在使用并将继续使用（尽管我和你一样不喜欢）。许多组织多年前就做出了技术决策，并且没有理由改变。
不过，我确实认为您是在谈论成熟的商店，人们对维护/增强已编写的内容而不是停留在最前沿更感兴趣。
MFC Feature Pack（一两年前，iirc）的发布是大约 10 年来 MFC 的最大扩展，它为 MFC 的开发提供了全新的推动力。我猜很多公司决定维护他们的遗留应用程序，推动它们向前发展并在其基础上开发新的应用程序。
对我（作为必须维护大型 MFC 应用程序的人）来说，更大的问题是（微软和第三方）组件的开发和支持减少，而不是 MFC 本身。例如，如果在应用程序中组装了许多旧的和不受支持的纯 32 位 Active-X 组件，那么移植到 64 位并不容易。
I did a project last year based on MFC. I'm not sure why MFC was chosen, but it was adequate for making a virtual 3D graphic user interface—a building management security system—with 10 frame per second refresh rate run efficiently on win32-based PCs dating back to the mid-1990s. The executable (which requires only core win32 system DLLs) is less than 400K—not an easy accomplishment with modern tools.
There are advantages to staying away from managed code (maybe you're writing a driver UI, or doing COM).
That and there's tons of MFC code out there. Maybe you work for Company X, and need to use one of the zillion DLLs they've been writing over the last dozen years.
我可以想到一个商业软件名称，它从使用 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