C++ MFC 与 .NET？

Question

我的同事正在使用 Visual Studio 2002 并使用 C++ MFC。 我正在用 C# 开发。

之前没出过什么问题，但是现在质疑我们的客户是否真的应该在不同的环境中开发。 我的同事认为（当然）我应该转向 C++ MFC。 我认为他们可以使用 .NET 而不是 MFC。

学习MFC有什么意义吗？ 感觉有点过时了，还是我错了？ 与 MFC 相比，反对和支持 .NET 的论据是什么？

编辑：

我们正在为核工业开发过程系统和辅助应用程序。 主要应用程序是一个仿真器，它模拟旧计算机系统并使用 C++/MFC。 这是非常关键的，也许核心应该仍然是原生 C++。 但是模拟器和所有周围应用程序的 GUI 并不是特别重要。

是否有任何真正的理由应该替换现有的 MFC 应用程序？

Answer 1

我已经广泛使用 MFC 和 Windows 窗体很长时间了。 我来自视频游戏行业，因此多年来不得不编写许多桌面应用程序，在 .net 之前，MFC 非常有用。 甚至在此之前，我都是在纯 Win32 中编写工具。

MFC 肯定有它的怪癖，但总的来说它让生活变得更轻松。 将 OpenGL 和 Direct3D 集成到自定义视图中非常容易，一旦掌握了它，编写自定义控件就是小菜一碟。 最重要的是，我可以用纯 C++ 编写代码，这恰好是我选择的语言。 另外，我发现 MFC 非常高效和活泼。

渐渐地，MFC 开始获得外部控件库支持，尤其是停靠/工具栏库，所以我的工具，如 3D 模型查看器和关卡编辑器，看起来都非常可爱。

我编写的大多数应用程序都以编程方式创建了 UI，因此对话框/窗口布局工具足以满足我的需求。

MFC 9 也很酷，尤其是 Microsoft 作为 Feature Pack 的一部分发布的 Ribbon control/docking 库。 所以老狗还有生命，这是肯定的！ :)

当 .net 1.0 出现时，我发现转换相当容易，因为它支持托管 C++。 它并不漂亮，但为 .net 框架提供了一个相对简单的入口。 但是当我开始编写更需要 Windows 窗体设计器的工具时，我的转折点就出现了，大约在 .net 2.0 时代。 我决定重新开始并学习我喜欢的 C# - 尽管我永远不会习惯没有 delete() ;) 的 new() 。 然后我开始编写用户控件，发现整个体验非常好和简单。 .net 框架是巨大的，得到了​​很好的支持，而且通常我发现在 C#/.net 中做几乎所有事情都更容易。 此外，编译速度快如闪电，而且在 Visual Studio 中重构的能力非常棒。

c#/.net 的美妙之处在于它并不仅限于编写托管代码。 如果性能是一个问题，或者如果您需要在平台之间共享代码，您仍然可以使用非托管代码。 例如，我的数学库是用 C/C++ 编写的，我将其放入一个库中，使 C# 能够包装/使用相同的代码，尽管这只是暂时的。 我也将及时将这些库移植到 C#，因此一切都是纯 .net。

我想提的最后一个经验是，过去几个月我一直在远离主机游戏编程，而是花时间为 InterWeb 编程。 我一直在使用 Microsoft 堆栈，在 ASP.net/C# 中编程，我不得不说它非常好，所有 C# 知识都直接适用。 唯一的学习曲线是 ASP.net，而不是语言和支持库。 随着 .net 3.5（LINQ 是甜蜜的）的到来，C# 的 .net 框架中的生活很可爱。

无论如何，我不想把它变成我的生活故事，但我只想简要介绍一个已经通过您所询问的所有技术的人的经历。 我还想提一下，尝试不同的语言/框架对您有好处。 我已经为 iPhone 编写代码一年了，并且已经变得非常喜欢 Objective-C。 都是编程，一切都很好。

关于 MFC/.net，两者都有其优点和缺点，我真的不介意 MFC，但就前进而言，我可能会坚持使用 C#/.net，但是拜托，拜托，拜托了解它是如何工作的。 我要说的唯一说教是了解 .net 中的内存是如何工作的，即使“一切都为您处理好了”；)

你对 C/C++ 的了解应该完全独立于你是否使用 MFC，它仍然是一种关键语言（尤其是在基于控制台的视频游戏编程中），但对于 Windows 上的桌面应用程序编程，它越来越难以反驳。网。 它快速、简单、有很好的工具支持、优秀的 3rd 方库、一个庞大的成长社区、现在是跨平台 (Mono) 并且将使您能够在所有当前/新兴的 Microsoft 技术（ASP.net、WPF、Silverlight、WCF）之间移动等等）。

尽管如此，我仍然将 Visual Studio 设置为 C++ 环境。 有些习惯永远不会消失;)

Answer 2

MFC 和 .NET 几乎处于相反的极端，每个都以自己的方式彻底蹩脚。

使用 MFC 大致相当于生活在二战剩余建筑的腐烂残骸中。 没有任何警告危险区域的迹象，并且可能不会立即清楚在哪里可以找到自来水、电或可用的厕所——即使它们都在那里，如果你知道如何找到它们。 像任何腐朽的建筑物一样，墙壁上有很多洞等等，因此您可以随时离开。 同样，从外部世界中拖入事物也很容易，尽管您可以通过“拖拽”来实现它。

使用 .NET 就像生活在杜鲁门秀的片场。 它符合人们对现实生活应该是什么样子的看法。 在它的边界内，生活似乎是乌托邦式的。 然而，归根结底，它只不过是一个装饰精美的牢房，它所描绘的生活都不是真实的。 你与外界的所有互动都受制于一位主要目的是提高自己收视率的导演的心血来潮； 你的福利只在影响他的范围内被考虑。

与大多数监狱不同，.NET 确实有一个标记清晰的逃生路线（标记为“P/Invoke”）。 然而，就像任何好监狱的逃生路线一样，这是一条一英里长的污水管道。 大多数居民都知道它的存在，但几乎唯一去那里的是青少年证明了他们的男子气概。 真正使用它的少数人只是在迫不得已时才这样做。 我们中那些经常觉得有必要的人已经意识到最好呆在外面而不是回去。

编辑：由于有些人希望圆圈和箭头以及每个圆圈和箭头的背面都用作法庭上的证据：MFC 的优势和劣势在于它主要是围绕 API 的相当薄的包装。 这是一个弱点，因为它的覆盖范围有相当多的漏洞，并且因为它在“平滑”API 本身不能特别好地组合在一起的地方方面做得相对较少。 例如，如果某些东西是使用 COM 实现的，那通常会直接显示在使用它的代码中。 这是一个优势，因为扩展 MFC 以处理默认情况下不处理的区域相当容易，并且在需要时可以简单地绕过它并直接使用 API。 它的更新频率也相对较低，因此虽然它目前可以生成外观相当“现代”的应用程序，但情况并非总是如此。 鉴于它的历史，很难预测它会继续如此。

.NET 的优势和劣势在于它是围绕 API 的“更厚”的包装器。 “平滑”API 中的差异要做得更多，因此（例如）在 COM 中实现的部分与作为直接 C 函数调用实现的部分看起来/行为没有明显不同。 在 .NET 内部，差异消失了。 .NET 是（目前）Microsoft 最喜欢的技术，因此它更新得更频繁，并且在确保您的 UI 遵循最新指南方面做得更好。 我的猜测是它比 MFC 更有可能继续这样做一段时间。

.NET 的弱点是绕过或扩展要困难得多。 基本上，您通往外部世界的唯一途径是通过 P/Invoke。 即使是短途旅行，也是丑陋而痛苦的。 尝试经常使用它或用于任何接近主要扩展的东西是受虐狂的练习。

如果（几乎）您编写的所有内容都适合 .NET 支持的内容，那么这是一个明确的选择。 只要您保持在其边界内，它就会更干净、更顺畅。

如果您编写的代码经常需要超出框架支持的范围，那么 MFC 可能会更好地为您工作。 使用 .NET，.NET 模型适用于您的整个程序。 使用 MFC，编写将 MFC 用于 UI 的程序相对容易，并且可以随心所欲地处理 MFC 不支持的其他任何事情。

Answer 3

我认为了解 C++ 是有价值的，因为该语言将存在很长时间。 您永远不知道什么时候可能需要使用 C++ 编程，而在当今的就业市场中，掌握更多语言只会增强您的简历。

至于MFC ，我正在尽力摆脱它。 它的计算标准已经过时（我认为接近 20 年），但 Microsoft 仍然看到通过新版本和功能包支持它的价值。 从这个角度来看，我怀疑 MFC 会很快消失。 但这并不意味着我想用它编程。 一周中的每一天，C# 编程的流畅性和易用性都让 MFC/C++ 大吃一惊。 线程、套接字、字符串操作等 - 所有这些事情在 C# 中比在 C++ 中更容易完成。 另外，C#/.NET 是 Microsoft 的主要技术重点，在职业发展方面，我宁愿处于这一边缘而不是 MFC。

Answer 4

这不是一个对另一个。 从 1.1 版开始，Windows 窗体支持由本机客户端（如 IE 或 MFC 对话框）托管。 MFC 8.0 在其 Windows 窗体支持类中封装了必要的托管代码，因此您无需编写自己的代码。 根据您当前项目的要求选择正确的库。

然而，MFC 不仅仅是它的 GDI 包装类。 曾经，它被设计为底层 Win32 API 的 OOP 替代品，与今天的 .Net 非常相似。 然而，MFC 并没有阻止 Win32 API 的增长，现在我可以说 Win32 API 的增长超出了 MFC 的支持范围。 API 的数量在过去十年中增加了数十倍。

另一方面，Windows Forms 旨在替代 Windows 的 GDI 系统。 .NET Framework 库的其余部分旨在替换 Win32 的其余部分，例如用于 DirectX 的 WPF 和 XNA 和用于 SAPI 的 System.Speech。 但是，我可以看到 win32 API 的增长超出了 .Net 可以在几年内没有显着增加下载大小的情况。

因此，Windows 窗体不能做 MFC 能做的所有事情，它旨在使基于 GDI+ 的 RAD 更容易，并且可能包括 MFC 不能做的事情。 然而，随着微软重新关注 WPF，基于 GDI+ 的 Windows 窗体正在走下坡路，而 MFC 则根据消费者的要求复兴。 如果您正在为未来的应用程序设计，您可能需要考虑到这一点。

Answer 5

您要解决的问题是什么？ 假设您同样了解 C++/MFC 和 C#/.NET。 哪个工具集可以让您更好地构建和维护？ （更好是主观的，但这同样取决于您的目标）

除非我使用 .NET 中不可用的本机 API 进行大量工作，否则到目前为止我将使用 .NET。 C++ 是一种很棒的语言，没有什么可以阻止您使用托管 C++ 进行编码以保持 .NET 框架和内存管理。

相比之下，我的观察是，与 .NET Windows 窗体相比，MFC 框架非常笨拙且笨拙。

Answer 6

MFC 提供的一项很好的功能是文档/视图框架（单个文档或多个文档），它在 .NET 中尚不具有等效性。 当您需要创建像 Microsoft 的 Word 一样工作的应用程序时，此功能非常有用和方便。 它有助于将数据模型与您想要呈现给用户的视图分开。 我认为一旦实现了这个功能，大多数人都会跳到 .NET 方面。 （微软是否正在为此努力，或者至少有计划在这方面开展工作？）

Answer 7

这个选择有很多优点/缺点。 MFC 是旧的备用设备，它已经存在了很长时间并且确实显示了它的年龄。 另一方面，它仍然得到很好的支持，MS 不断更新它以保持最新状态。

.Net 框架有更好的支持，因为它有一个更大的团队支持它，并且被视为构建 Windows 新部分的东西。

另一方面，MFC 是 Windows 生态系统的重要组成部分。 如果您在该平台上编程，那么当您最终支持 MFC 应用程序时，至少了解 MFC 的作用以及如何工作是值得的（别担心，总有一天你会）对从哪里开始有一个良好的基础。

Answer 8

一年多前，我从 C++/MFC 过渡到 C#/WinForms（大器晚成，我知道 ;)）。

撇开语言差异不谈，从 MFC 过渡到 WinForms 要比其他方式容易得多。 如果您打算有效地维护遗留应用程序，我认为了解 MFC 绝对有价值。 然而：

我会从头开始学习 MFC（考虑到现有技术）吗？ 不，可能不是。
我会在 MFC 中编写新的应用程序吗？ 不，可能不是。

.NET 的支持、灵活性和易用性远远超过了 MFC 的优势。 就其本身而言，MFC 非常棒，我很感激有机会使用它——它教会了我很多。 但最终，它正在走出去。

Answer 9

天啊。 我知道我参加这个派对已经很晚了，但作为一个用 C 和纯 Win32 编写的人，然后他的大部分职业生涯都是在 C++/VC/MFC 上，用 C# 和 WPF 编写是一种痛苦！！ 我知道我是新手，但我强迫自己用 C# 编写这个小应用程序，因为我想更适应 C#/.NET 和 WPF。 虽然很高兴我能够轻松地使 UI 成为光滑的黑色，但我需要花费时间来定义菜单，当在 MFC 中时，我会创建菜单资源，添加菜单项，然后添加事件处理程序到他们轻松！ 这是苦差事。 我喜欢 C# 作为一门语言，但如果我能像在 MFC/Windows 的资源编辑器中一样定义一切，并添加像 WPF 那样使 UI 元素变得活泼的能力，我会更喜欢它。

Answer 10

非托管代码不一定执行得更快，这取决于编写的代码以及编写代码的人。 我读过一些复杂的基准测试报告（源代码、代码项目），C# 在某些方面胜过 C++，C++ 在其他方面胜出。 这取决于您的领域：我为飞行模拟器编写软件，因此需要一个非托管环境。 如果您正在制作 GUI 应用程序，C# 可能是更好的选择。 对于低级别套接字编程，C++ 可能会返回更好的结果。 我注意到在正常操作中 C++ 和 C# 之间没有严重的速度差异，但我喜欢 C++ 的本机可移植性和 C# 的易用性。

Answer 11

.NET 使用托管代码。 MFC 使用非托管代码。 我读过非托管代码的执行速度比托管代码快。 因此，如果您正在开发软实时代码，您可能希望使用非托管代码。