还有MFC的案例

17
投票

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

奇趣科技的QT是一个更好的选择，有一个很大的优势 - 它独立于平台。使用MFC，你注定要注意Windows。

2
投票

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

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

1
投票

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

另一方面，诸如雇用能力，培训计划和第三方组件等外部因素仍可延长其使用寿命，至少对于某些类型的应用程序：小而简单，针对特殊应用而用户相当少，最好在公司内部。

1
投票

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

1
投票

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

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

0
投票

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

如果你想看一眼，那就是LGPL，它位于：

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

10
投票

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

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

8
投票

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

现在，如果你关注那些东西，那里有更好的替代品：C ++ Builder，WxWidgets等。但有些地方不会考虑非Microsoft工具。

8
投票

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

如果你打算开发一个仅在C ++中针对Windows的桌面应用，那么MFC是最成熟的选择，在互联网上有很多基于MFC的免费代码，知识很多。

7
投票

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

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

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

6
投票

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

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

4
投票

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

3
投票

我想不是.. MFC会输掉

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

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

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

3
投票

Quick Tour Of New MFC Functionality

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

（来源：msdn.com）

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

问题描述投票：18回答：14

14个回答

最新问题

还有MFC的案例

问题描述 投票：18回答：14

14个回答

最新问题

问题描述投票：18回答：14