Is There Still A Case For MFC

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

From stackoverflow

• 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:

  

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

  gbjbaanb : now you know what Office is written in, and what those guys want, they get. Sinofsky said the next release of VS would be focussed on C++, but we'll see about that when it arrives.

  Aaron Fischer : These new mfc controls were bought from BCGSoft, We could have bought them at any time.

• The advantage of MFC is that it's still nicer than coding to bare win32 and you can distribute a native .exe that doesn't require a 23-50Mb runtime like .Net.

  Now, if you're concerned about those things there are better alternatives out there: C++ Builder, WxWidgets, etc. But some places won't consider non-Microsoft tools.

  Asaf R : Personally, I prefer Win32 to MFC. I never found any seriously added value to MFC over Win32. Also, there's WTL which was pretty good several years ago and is probably great by now.

• Apparently it is still a good choice for applications for windows-based hand-held devices, such as point-of-sale devices. In these, resources are limited so things like memory management become more significant.

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

  shsteimer : In such a scenario you could develop the speed sensitive logic in c++, compile to a dll and then build the ui with C#.

  Corey Trager : In trading apps, the UI must also be fast, to keep up with last traded price, etc.

• The existing windows API is entirely C based. If you want to use C++ (and you probably should) then MFC is the logical choice if you wish to stay native (i.e. not using .NET).

  MFC is just a set of object-orientated classes over the top of the C API. Plus quite a few additional "helper" classes that make it easier to do everyday tasks.

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

  unforgiven3 : You could also consider WTL instead of MFC.

  Byron Whitlock : Wasn't MSOFFICE pre 2007 was written in MFC!? That is neither a small nor simple app.

  EFraim : @Byron: Actually my most negative sentiment about MFC is that it assumes you are writing MS Office application :) Really the document-view architecture has its merits, but for a minority (I think) of GUI applications.

• Here's a possibility - imagine an application that would require a large amount of memory, say a graphics program, a game or maybe some high performance business application. It's no secret that .NET applications hog memory - in such a case, you may want a lean MFC app for the core of your application. You can always load up and use .NET components, controls, etc through either COM callable wrappers or directly through C++/CLI.

  That all being said - MFC is a pain. Consider WTL instead - you can still call into .NET if you need to, the same way as I mentioned above for MFC. WTL is a lot nicer than MFC :-)

  Jeff Yates : I used to love WTL on my old project. :)

• MFC was good option 10 years ago. It is still a good wrapper over Win32 API but unfortunately obsolete.

  Trolltech's QT is better option with one big advantage - it is platform independent. With MFC you're doomed to Windows.

  Paul Dixon : +1 from me, I loved the leap from MFC to Qt ;)

• 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/

• I think not.. MFC would lose out in

  • Level of abstraction
  • Development Time
  • Troubleshooting time
  • Learning curve for new developers
  • Future proofing (although now that's questionable.. with something new coming up every 3-4 years)
  • Finding good people who know their MFC
  • Easy to use controls

  The only place where MFC would probably sneak past is if you have some very performance intensive applications like you have things on screen that need to be redrawn every 10 msec or 1 sec. "Managed" apps still haven't managed to jump past that hurdle.

  MFC was an important step in the evolution, but now better options are available.

• If you are developing Windows CE and mobile apps in C++, as Einar has already mentioned, MFC is a good choice. If you make this choice, MFC then also becomes a reasonable choice for the desktop as you can use the same code across desktop and hand-held devices. MFC remains a good perfomance / easy to implement combinitation in this scenario. Personally, I use MFC in conjunction with Stingray libraries in these enivornments which gives a very good interface, good performance and is quick and easy to implement.

• I still use MFC for all kinds of applications. MFC got a bad rap from it's early implementations, but it is excellent now. I find it quite a bit more convenient than WTL as well. Plus the GUI tools in Visual Studio are already setup to make it easy to rapidly develop GUIs with MFC, mapping controls to variables, DDX, etc.

  For desktop applications that I intend for wide distribution I still go with native Windows applications, usually in MFC, because we're still not at a point where you can depend on your customers to have the version of .NET that you'll be using installed and asking them to install it will cause you to lose sales, not to mention the customer service headache when they run into problems installing .NET as a result of trying to get your app to run.

  EFraim : Sorry, adequate, bearable is OK, excellent is absolutely unwarranted. I cannot wholeheartedly call something which leaks all possible Win32 details as an *excellent* abstraction. You have to know Win32 by heart AND THEN some additional MFC specific quirks (for instance related to message maps)

  Gerald : I'm pretty sure I never said "excellent abstraction". It's not meant to hide the details of the Win32 API, it's meant to provide a means to develop applications that use the Win32 API faster, and more uniformly, while still making it easy to call directly into the Win32 API when necessary or convenient. At that, it is excellent.

  EFraim : No, it does not help develop them faster, if I have to understand all the intrinsics of Win32 API. And if I do, then I see little point in using MFC. WTL or straight Win32 API are much more clear - and generally more adaptable for embedding in application logic.

  EFraim : Let me clarify my position on this: MFC might be OK for supporting legacy MFC code. It might be OK when developing fast prototype of something you don't want to bring another library in. (since it is shipped with VC++) But for developing modern applications, with things like resizable dialogs (b.t.w. non-resizable dialogs is a single most-hated thing for me in a GUI application - they never are quite the size you want), dockable toolbars - it is simply not "excellent". Maybe adequate with some hacks like ETSLayout.

  Gerald : If you don't already know the Win32 API, then it's not for you, but if you do it most certainly does help you develop them faster. Or, at least, it helps me, and many like me. I use Qt for most of my cross-platform GUI development, but I still prefer MFC when developing for Windows only, for the very reason it exists; to eliminate a lot of the repetitive gruntwork of working with the Win32 API, while still giving you full control and access to the underlying API.

  Gerald : And I'm not sure what problems you have with it, but resizable dialogs and dockable and/or floating toolbars are all trivial under MFC. Actually much easier to get them to behave exactly the way you want than under Qt or any other abstracted GUI library that I've used.

  EFraim : Resizable dialogs are *trivial*? Now I really want to know what MFC version you are using. (Because they are not) Anyway, I have no problem with Win32 API pre se, however I see MFC as adding lots of clusmy cruft around with really no added value (Actually every design I could think of myself, or every ready toolkit like WTL suited this case much better)

  Gerald : You capture the resize/ing messages, and you resize your controls accordingly, it's not hard. You don't get the fancy layout managers that give you automatic resizing, but my experience with those has been that, except in the simplest cases, they never give you exactly what you want. I can't say that I see the "clumsy cruft" you're talking about. Any concrete examples?

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