C# C++ MFC 与 .NET？

C++ MFC vs .NET?

提问by magol

My colleagues are using Visual Studio 2002 and uses the C++ MFC. I am developing in C #.

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

It has not been any problems before, but now questioning our customers if we really should develop in different environments. My colleagues think (of course) that I should move to C++ MFC. I think that they can use .NET instead of MFC.

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

Is there any point to learn the MFC? It feels a bit outmoded, or am I wrong? What are the arguments against and for .NET compared with MFC?

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

Edit:

编辑：

We are developing process systems and assistance applications for the nuclear industry. The main application is an emulator that emulates an old computer system and uses C++/MFC. It is very time critical, maybe the core should it still be in native C++. But the GUI to the emulator and all surrounding applications are not particularly critical.

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

And is there any real reason that you should replace the existing MFC application?

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

采纳答案by Shane

I've used both MFC and Windows Forms extensively for a very long time. I'm from the video game industry, so have had to write many desktop applications over the years, and before .net, MFC was extremely useful. Even before that I was writing tools in pure Win32.

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

MFC definitely had its quirks, but overall it made life a lot easier. It was very easy to integrate OpenGL and Direct3D into custom views, and once you got the hang of it writing custom controls was a piece of cake. Best of all, I could just code in pure C++, which just happened to be my language of choice. Plus I found MFC to be very efficient and snappy.

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

Gradually MFC started to get external control library support, particularly docking/toolbar libraries, so my tools like 3D model viewers and level editors, all looked pretty sweet.

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

Most applications I wrote created the UI programmatically, so the dialog/window layout tool was more than adequate for my needs.

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

MFC 9 is pretty cool too, especially with the Ribbon control/docking library that Microsoft has released as part of the Feature Pack. So there is life in the old dog yet, for sure! :)

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

When .net 1.0 came out I found the transition fairly easy, because it supported managed C++. It wasn't pretty, but gave a relatively straightforward on-ramp to the .net framework. But the tipping point for me came when I started to write tools that needed the Windows Forms Designer more, around the time of .net 2.0. I decided to start again and learn C#, which I loved - although I'll never get used to having new() without delete() ;). I then started writing user controls, finding the whole experience very nice and straightforward. The .net framework was huge, well supported, and generally I found it easier to do just about everything in C#/.net. Plus, compilation was lightning fast, and the ability to refactor in Visual Studio was awesome.

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

The beauty of c#/.net is it doesn't limit you to just writing in managed code. You can still use unmanaged code, if performance is an issue for instance, or if you need to share code between platforms. For instance, my math libraries are written in C/C++, which I put into a libraries enabling C# to wrap/use the same code, although that's only temporary. I'm going to port those libraries to C# in time too so everything is pure .net.

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

The last experience I want to mention is that I have been spending the last few months away from console game programming, and spending time programming the InterWeb. I've been using the Microsoft stack, programming in ASP.net/C#, and I have to say it's very nice, with all of the knowledge of C# directly applicable. The only learning curve was ASP.net, not the language and support libraries. With the arrival of .net 3.5 (LINQ is sweet) life in the .net framework with C# is lovely.

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

Anyway, I don't want to turn this into my life's story, but I just wanted to give a brief experience of someone who has moved through all of the technology you've asked about. I'd also like to mention that it's good for you to try different languages/frameworks. I've been coding for the iPhone for a year now, and have grown to really like Objective-C. It's all programming, and it's all good.

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

With respect to MFC/.net, both have their pluses and minuses, and I really don't mind MFC at all, but in terms of moving forward, I'd probably stick to C#/.net, but please, please, please understand how it works. The only preachy thing I'll say is to understand how memory in .net works, even though 'it's all taken care of for you' ;)

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

Your knowledge of C/C++ should be completely independent of whether you use MFC or not, it's still a critical language (particularly in console-based video game programming), but for desktop application programming on Windows, it's getting harder and harder to argue against .net. It's fast, easy, has great tool support, excellent 3rd party libraries, a huge growing community, is now cross platform (Mono) and will enable you to move between all current/emerging Microsoft technologies (ASP.net, WPF, Silverlight, WCF etc).

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

For all of this, though, I still set up Visual Studio as a C++ environment. Some habits never die ;)

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

回答by u109919

It is not one vs. the other. Since version 1.1, Windows Forms supports being hosted by native clients such as IE or MFC dialog. MFC 8.0 wrapped the necessary hosting code in it's Windows Forms support classes so you don't need to write your own. Choose the right library based on your current project's requirements.

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

MFC is more than its GDI wrapper classes, however. At one time it designed as the OOP replacement for the underlying Win32 API, pretty much like .Net today. However, MFC did not stop the Win32 API from growing and now I can say win32 APIs grow out of what MFC can support. The number of APIs increased dozens of times in the last decade.

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

Windows Forms, on the other hand, was meant to be a replacement only for Windows's GDI system. It's the rest of the .NET Framework libraries that are meant to replace the rest of Win32, like WPF and XNA for DirectX and System.Speech for SAPI. However, I can see win32 APIs grow out of what .Net can keep up without adding downloading size significantly in a few years.

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

Therefore Windows Forms cannot do everything MFC can do, it is designed to make GDI+ based RAD easier and may include what MFC can't do. However the GDI+ based Windows Forms is going downhill as Microsoft's refocus on WPF, while MFC revived based on consumer request. If you are designing for future applications you may want to take that into consideration.

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

回答by Matt Davis

I think there's value in knowing C++ since the language will be around a long time. You never know when programming in C++ may be required, and in today's job market, having more languages under your belt only enhances your resume.

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

As for MFC, I'm trying my best to pull away from it. It is old by computing standards (approaching 20 years, I think), but Microsoft still sees the value in supporting it with new releases and feature packs. From that standpoint, I doubt MFC will go away anytime soon. But that doesn't mean I want to program with it. The fluidity and ease with which one can program in C# beats the pants off MFC/C++ every day of the week. Threading, sockets, string manipulation, etc. - all of these things are simply easier to do in C# than in C++. Plus, C#/.NET is the primary technology focus for Microsoft, and I'd rather be on that edge than the MFC backburner when it comes to career development.

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

回答by sizzle

.NET uses managed code. MFC uses unmanaged code. I have read that unmanaged code executes faster than managed code. So if you are developing soft real-time code, you may want to use unmanaged code.

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

回答by Fox Cutter

There are a lot of pros/cons in this choice. MFC is the old stand by, it's been around for ages and does show its age. On the other hand it's still fairly well supported and MS keeps updating it to stay current.

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

The .Net framework has better support as it has a larger team backing it and is seen as something to build new parts of Windows on.

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

On the other hand, MFC is a big part of the Windows Ecosystem. If you're programing on the platform it will be worth it to have at least a working knowledge of what MFC does and how so when you end up supporting an MFC app (and don't worry, some day you will) you'll have a good grounding on where to start.

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

回答by spoulson

What is the problem you're looking to solve? Suppose you know both C++/MFC and C#/.NET equally. Which toolset would let you build and maintain better? (Better is subjective, but again that depends on your goals)

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

Unless I'm doing a lot of work with native APIs that aren't available in .NET, I will go with .NET by far. C++ is a great language and nothing's to stop you from coding in Managed C++ so as to keep the .NET framework and memory management.

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

By comparison, my observation is the MFC framework is very much a kludge and unwieldy compared to .NET Windows forms.

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

回答by Jerry Coffin

MFC and .NET are at nearly opposite extremes, each thoroughly crappy in its own way.

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

Using MFC is roughly on the order of living in the decaying wreck of a WW II surplus building. There aren't any signs to warn about dangerous areas, and it's probably not immediately apparent where to find running water, electricity, or a toilet that works -- even though all of them are there, if you know how to find them. Like any decaying building, there are plenty of holes in the walls and such, so you can leave anytime you want for as long as you want. Likewise, dragging in things from the outside world is pretty easy, though it's pretty much up to you to do the "dragging" to get it there.

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

Using .NET is like living on the set of The Truman Show. It fits one person's idea of what real life shouldbe like. Within its boundaries, life can seem Utopian. In the end, however, it's little more than a pleasantly accoutered prison cell, and none of what it portrays as life is quite real. All your interaction with the outside world is subject to the whim of a director whose aims are mostly to improve his own ratings; your welfare is considered only to the extent that it affects him.

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

Unlike most prisons, .NET does have a well marked escape route (labeled "P/Invoke"). Like the escape route from any good prison, however, it's a mile-long sewage pipe. Most residents are aware of its existence, but nearly the only who go there are teenagers proving their manliness. The few who put it to real use do so only in dire necessity. Those of us who found it necessary once too often have realized it's better to just stay outside and not go back in.

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

Edit: Since some people want circles and arrows and a paragraph on the back of each one to be used as evidence in court: MFC's strength and weakness is that it's mostly a fairly thin wrapper around the API. That's a weakness because there are a fair number of holes in its coverage, and because it does relatively little to "smooth over" the places that the API itself doesn't fit together particularly well. For example, if something is implemented using COM, that will usually show up directly in your code that uses it. It's a strength, because it's fairly easy to extend MFC to handle areas it doesn't by default, as well as to simply bypass it and work directly with the API when you need to do so. It's also been updated relatively infrequently, so while it can currently produce reasonably "modern" looking applications, that hasn't always been the case. Given its history, it would be hard to predict that it'll continue to be the case.

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

.NET's strength and weakness is that it's a much "thicker" wrapper around the API. It does considerably more to "smooth over" differences in the API, so (for example) parts that are implemented in COM don't look/act noticeably different from parts that are implemented as straight C function calls. From inside .NET, the differences disappear. .NET is (currently) Microsoft's favored technology, so it's updated much more regularly, and does a much better job of ensuring that your UI follows the latest guidelines. My guess is that it's much more likely than MFC to continue doing so for some time.

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

The weakness of .NET is that it's much more difficult to bypass or extend. Basically, your only route to the outside world is through P/Invoke. Even for small excursions, it's ugly and painful. Trying to use it very often or for anything approaching a major extension is an exercise in masochism.

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

If (nearly) everything you write can fit within what .NET supports, it's the clear choice. It's much cleaner and smoother as long as you stay inside its boundaries.

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

If you write code that fairly frequently needs to go outside the bounds supported by the framework, MFC will probably work much better for you. With .NET, the .NET model applies to your wholeprogram. With MFC, it's relatively easy to write programs that use MFC for their UI, and do things however they want for anything else that MFC doesn't support.

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

回答by Jon Seigel

I transitioned from C++/MFC to C#/WinForms just over a year ago (late bloomer, I know ;) ).

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

Language differences aside, it's going to be far easier to transition from MFC to WinForms than the other way around. I think there is definitely value in knowing MFC if you intend to be effective at maintaining legacy applications. However:

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

Would I learn MFC from the ground up (given existing technologies)? No, probably not.
Would I write new applications in MFC? No, probably not.

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

The advantages of MFC are far outweighed by the support, flexibility, and ease of use of .NET. For what it is, MFC is superb, and I'm grateful for the opportunity to have worked with it -- it taught me a lot. Ultimately, though, it's on its way out.

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

回答by Collin Biedenkapp

Unmanaged code does not necessarily execute faster, it depends on the code written, and the one writing the code. I have read some sophisticated benchmark reports (source, Code Project), and C# beat C++ in some respects, C++ won in others. It depends on your field: I write software for Flight Simulators, hence needing an unmanaged environment. If you are making a GUI application, C# may be the better choice. For low lever socket programming, C++ may return better results. I have noticed no serious speed difference between C++ and C# in normal operations, but I am a fan of C++ for its native portability and C# for its ease.

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

回答by david

One nice feature that MFC provides is the Document/View framework (single document or multiple documents) which didn't have the equivalence in .NET yet. This feature can be quite useful and handy when you need to create application that works like Microsoft's Word. It helps separate the data model from the view you want to represent to users. I think most people will jump to the .NET side for good once this feature has been implemented. ( Is Microsoft working on this or at least has plans to work on this?)

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