还有MFC的案例

Question

MFC有哪些引人注目的功能？为什么要为新项目选择它？

Answer 1

10年前，MFC是不错的选择。它仍然是Win32 API的一个很好的包装，但不幸的是已过时。

Trolltech的QT是一个更好的选择，有一个很大的优势 - 它与平台无关。使用MFC，你注定要注定Windows。

Answer 2

我仍然将MFC用于各种应用程序。 MFC从它的早期实现中获得了糟糕的说法，但它现在非常出色。我发现它比WTL更方便。此外，Visual Studio中的GUI工具已经设置好，可以使用MFC快速开发GUI，将控件映射到变量，DDX等。

对于我打算进行广泛分发的桌面应用程序，我仍然使用本机Windows应用程序，通常是在MFC中，因为我们仍然不能依赖于您的客户拥有您的.NET版本将使用已安装并要求他们安装它将导致您失去销售，更不用说客户服务因为试图让您的应用程序运行而遇到安装.NET的问题而头疼。

Answer 3

MFC的优势在于它仍然比编写裸机win32更好，你可以发布一个不需要23-50Mb运行时的原生.exe，如.Net。

现在，如果您关心那些事情，那里有更好的替代品：C ++ Builder，WxWidgets等。但有些地方不会考虑使用非Microsoft工具。

Answer 4

你可以改写这个问题，为什么你会为桌面应用程序选择C ++而不是C＃。 C ++仍然提供速度优势，这对某些应用程序很重要（我为一家为电子交易创建软件的公司工作。速度很重要）。

如果您打算开发一款仅适用于C ++的Windows桌面应用程序，那么MFC是最成熟的选择，在互联网上有大量基于MFC的免费代码，知识渊博。

Answer 5

除了win32 api本身，MFC是唯一的主流Windows编程技术，在2011年经过15年以上仍然存在。早在2001年，每个人都说'MFC已经死了，现在所有的Winforms';在2005年，每个人都说'MFC已经死了，现在都是XAML';现在是2011年，Winforms和XAML已经死了（OK XAML可能并没有真正死亡，但已经过了巅峰期），MFC仍然在更新最新的发展（功能区，Aero扩展，Win7 API等）。

当然，这不能保证未来的任何事情，但在超过15年的时间里，写了很多很多的MFC代码，它将在未来十年或几十年内继续使用。它可能不是最漂亮的技术，但它很好理解（它的优点和缺点）并且不像其他炒作技术那样是一个移动目标，这意味着真正想要完成任务的人可以依赖它（更多而不是替代品，无论如何）。

（同样适用于C ++，顺便说一下）

Answer 6

这是一种可能性 - 想象一个需要大量内存的应用程序，比如图形程序，游戏或者某些高性能的业务应用程序。 .NET应用程序占用内存已经不是什么秘密 - 在这种情况下，您可能需要一个精简的MFC应用程序作为应用程序的核心。您始终可以通过COM可调用包装器或直接通过C ++ / CLI加载和使用.NET组件，控件等。

所有人都说 - MFC是一种痛苦。请考虑使用WTL - 如果需要，您仍然可以调用.NET，就像我上面提到的MFC一样。 WTL比MFC好很多： - ）

Answer 7

显然，对于基于Windows的手持设备（例如销售点设备）的应用程序来说，它仍然是一个不错的选择。在这些方面，资源有限，因此内存管理等内容变得更加重要。

Answer 8

Quick Tour Of New MFC Functionality

我听说他们有一个新的色带控制。如果你遇到这种复杂性。这是新生成的应用程序的屏幕截图：

_{（来源：msdn.com）}

真的，这只是一个小部件更新。那么我们需要更多的小部件吗？

Answer 9

我认为不是...... MFC会输掉

• 抽象程度
• 开发时间
• 排除故障时间
• 新开发人员的学习曲线
• 未来的证明（尽管现在这是有问题的......每3 - 4年会有新的事情发生）
• 找到了解MFC的好人
• 易于使用的控件

MFC可能会过去的唯一地方是，如果你有一些非常高性能的应用程序，比如屏幕上的东西需要每10毫秒或1秒重绘一次。 “管理”应用程序仍未设法跳过这个障碍。

MFC是发展过程中的重要一步，但现在有了更好的选择。

Answer 10

现有的Windows API完全基于C语言。如果你想使用C ++（你可能应该），那么如果你希望保持原生（即不使用.NET），MFC是合乎逻辑的选择。

MFC只是一组面向对象的类，位于C API的顶部。还有一些额外的“帮助”类，可以更轻松地完成日常任务。

Answer 11

设计与开发单靠技术优点？很抱歉是绝对的，但没有。这是一个糟糕的设计，一个巨大的漏洞抽象，你必须回退到Win32 API编程，严重误用C ++，并坚定地瞄准昨天的技术：你不会得到一个现代（甚至有吸引力！）用户体验一个MFC应用程序。如果您可以获得C＃开发人员并且没有严重的硬件限制，请使用WinForms。

另一方面，外部因素，例如雇用，培训计划和第三方组件的可用性，仍然可以延长其寿命，至少对于某些类型的应用：小型和小型应用。简单，针对特殊应用，用户数量相当少，最好是内部使用。

Answer 12

如果您正在使用C ++开发Windows CE和移动应用程序，正如Einar已经提到的那样，MFC是一个不错的选择。如果您做出这个选择，MFC也可以成为桌面的合理选择，因为您可以在桌面和手持设备上使用相同的代码。在这种情况下，MFC仍然是一个很好的性能/易于实现组合。就个人而言，我在这些环境中将MFC与Stingray库结合使用，这样可以提供非常好的界面，良好的性能并且快速且易于实现。

Answer 13

我想说速度和足迹是.NET的理由。

很可能你会发现很难找到好的MFC程序员，但这也是因为现代语言促进了懒惰的编程技术，大多数编程课程都倾向于它们，因为它们更容易教授。

Answer 14

我已经编写了多年的跨平台代码，所以当我需要编写一些内容时，我总是在它之间有一个非常薄的抽象层，除了posix调用之外，几乎所有东西都会调用系统。这样你可以将它编码为MFC，但如果需要，可以很容易地将其转换为不同的API。我用于所有内容的我的基本c ++库集使用一个小的System类来完成。我目前使用MFC for Windows，我也使用XWindows for Linux和本机Mac版本。后来当我将它移植到掌上电脑时，它应该是非常轻松的。

如果你想偷看，那就是LGPL，并且在：

http://code.google.com/p/kgui/