C++ MFC vs .NET?

Question

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

It has not been any problems before, but now questioning our customers if we re

Answer 1

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.

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.

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.

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.

Answer 2

.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.

Answer 3

Oh man. I know I am super late to this party, but as someone who has written in C and pure Win32, and then the bulk of his career in C++/VC/MFC, writing in C# and WPF is a PAIN!! I know I am new, but I'm forcing myself to write this little application in C# because I want to be more comfortable with C#/.NET and WPF. While it is nice that I was able to make the UI a sleek black easily, the time it is taking for me to define a menu, when in MFC I would have created the menu resource, adding the menu items and then added event handlers to them with EASE! This is drudgery. I like C# as a language, but I would love this SO much better if I could define everything like I can in the resource editor with MFC/Windows AND add the ability to jazz up the UI elements like in WPF.

Answer 4

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.

Answer 5

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)

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.

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