Is There Still A Case For MFC

Question

What are the compelling features of MFC? Why would you select it for a new project?

Answer 1

Quick Tour Of New MFC Functionality

I hear they have a new ribbon control. If you're into this sort of complexity. Here's a screenshot of a newly generated app:

http://blogs.msdn.com/blogfiles/vcblog/WindowsLiveWriter/QuickTourOfNewMFCFunctionality_C777/Wizard%20Generated%20with%20accelerator%20tips_2.jpg

Really, it's just a widget update. So do we need more widgets?

Answer 2

Apart from win32 api itself, MFC is the only mainstream Windows programming technology that is still alive and well in 2011 after 15+ years. Back in 2001 everybody said 'MFC is dead, it's all Winforms now'; in 2005 everybody said 'MFC is dead, it's all XAML now'; now it's 2011 and Winforms and XAML are dead (OK XAML maybe not really dead, but way past its prime) and MFC is still being updated with the latest developments (ribbon, Aero extensions, Win7 API's etc).

Of course, that doesn't guarantee anything for the future, but over those 15+ years, a lot of MFC code written, and it will remain in use for the next decade or decades. It may not be the prettiest tech but it's well-understood (its good and bad points) and is not a moving target like other hype technologies are, meaning that people who actually want to get stuff done can sort of rely on it (well more than on the alternatives, anyway).

(same goes for C++, btw)

Answer 3

You could sort of reword the question, why would you select C++ over C# for a desktop app. C++ still offers speed advantages which matter for some applications (I work for a company that creates software for electronic trading. Speed matters a lot).

If you are going to develop a desktop app aimed for Windows only in C++, then MFC is the most mature choice, with lots of free code based on MFC on the internet, lots of knowledge.

Answer 4

I've written cross platform code for years so when I need to write something I always have a very thin abstraction layer between it and the system calls for almost everything except posix calls. That way you can code it go MFC but quite easily convert it a different API later if needed. My base set of c++ libraries that I use for everything does this with a small System class. I currently have it using MFC for Windows and I also have it using XWindows for Linux and a native Mac version as well. And later on when I port it for a handheld it should be quite painless.

If you want to take a peek, it's LGPL'ed and is at:

http://code.google.com/p/kgui/

Answer 5

On design & technical merits alone? Sorry to be categorical, but none. It's a poor design, a hugely leaky abstraction where you have to fall back to Win32 API programming, misuses C++ egregiously, and is firmly targeted on yesterday's technology: you won't get a modern (or even an attractive!) user experience out of an MFC app. If you can get C# developers and you don't have serious hardware limitations, go with WinForms.

External factors such as the availability of competence for hire, training programmes and third party components, on the other hand, can still extend its lifespan, at least for some kinds of applications: small & simple, targeted for special applications with reasonably few users, preferably in-house.

Answer 6

I would say that speed and footprint are good reasons over .NET.

It's probably true that you'll find it difficult to locate good MFC programmers, but thats just as much because the modern languages promote lazy programming techniques and most programming courses gravitate towards them as they are easier to teach.