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?

Solution 1

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

Solution 2

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

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.

Using .NET is like living on the set of The Truman Show. It fits one person's idea of what real life should be 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.

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.

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.

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

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.

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.

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

Solution 3

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.

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.

Solution 4

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

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

View more solutions

Comments

[Matt Davis]

C++ is to C# what MFC is to .NET. MFC is just a structured C++ framework around the Win32 API. For example, in .NET, there is the System.Threading.Thread class. The counterpart in MFC is CThread. It's System.String in .NET and CString in MFC. Generally, both MFC and .NET allow you to achieve the same goals. It's just that the .NET way of doing things is more flexbile, more expressive, and easier to use than MFC.

[pyon]

The runtime advantage of MFC compared to .NET is not that great. If you want speed, you should use raw C, no frameworks involved other than Win32 itself. And you can call it from .NET using P/Invoke.

[oltman]

-1 flaming with no actual justification or suggestions for a better platform

[Jerry Coffin]

Anybody who calls that flaming has never seen a real flame in his life. Suggestions for other platforms would be off-topic -- his question was specifically to compare these two.

[oltman]

Ok then, I'll call it bashing with no justification. Saying "LOL THEY BOTH SUCK" is completely useless to someone who is trying to decide on a development platform to suit the needs of his customers.

[Jerry Coffin]

Characterizing all I said as: "LOL THEY BOTH SUCK", is the part that's completely useless, and grossly inaccurate. Nonetheless, for those who need everything spelled out explicitly, I've added that.

[Matt Davis]

+1 very well said. If I could add a caution of my own when moving to C#/.NET, it's to understand the difference between value types (struct) and reference types (class). C programmers are comfortable with structs, and the move to C++ is benign because structs and classes are identical except for default visibility (structs use public visibility by default while classes use private visibility). In C#/.NET, however, classes and structs are completely different. Not understanding the difference can cause serious performance issues.

[Mordachai]

nit: MFC is to C++ what .NET is to C#

[Mordachai]

One thing worth noting: C/C++ don't load the .NET runtime, and therefore have fewer restrictions when it comes to what sort of stuff they can do at a lower-level with the OS. If your target software needs to interact at a low level, you really do benefit from being able to write at that level, and C/C++ is an excellent tool for that.

[pyon]

I don't understand why the downvotes. Myself, I upvoted this. This is actually a good answer in the sense that it shows something that other answers didn't focus on: the main limitations of both frameworks.

[pyon]

Indeed, MFC wasn't though for today. Back then, we couldn't afford downloading such a massive framework as .NET in every computer. We couldn't afford managed environments either. Java was the proof. Now, everything has changed. The main advantages of MFC have disappeared and while the main disadvantages remain. Having this in mind, .NET is the future.

[MrCC]

I actually liked that answer, as well. Though the fine nuances that are hidden in the 'picture language' in paragraphs 2-4 can only be understood by those who were forced to walk the COM Interop / PInvoke paths themselves. Nuances that less experienced programmers (oltman?) might not understand, or even appreciate. I recommend reading ".NET and COM: The Complete Interoperability Guide" by Adam Nathan for anyone who wants to learn more about the "sewage pipe" Jerry was talking about.

[red_rain]

+1 for mentioning the sewage pipe and naming the limitations of both frameworks.

[magol]

The applications that are using MFC do not use Document/View at all. They only view status of the process and allow the user to configure all the settings in a tree structure. So I rely don't see any reason to continue use MFC. And some of the developers have start to question MFC to. The question is HOW to migrate all the code

[Shyamal Desai]

Sad that WTL is not even considered. It lets you do pretty much everything that MFC lets you do. Its OPEN SOURCE. The size of the executable will be smaller by a degree than MFC. I have no basis to compare it to .net wpf. I can write more people are interested.

[magol]

I can agree with you to some extent. MPF is very complex, which is both its weakness and its strength. It is complicated to do simple things, but you also have the freedom to do almost anything you want.