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

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?

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.

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

Answer 1

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

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:

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

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.

Answer 2

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 3

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.

Answer 4

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 5

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

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

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.

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

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! :)

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.

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.

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.

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.

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' ;)

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

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