Reputation: 21211

Is There Still A Case For MFC

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

Upvotes: 20

Answers (14)

m_pGladiator

Reputation: 8620

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

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

Upvotes: 19

Frank Krueger

Reputation: 70983

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:

_{(source: msdn.com)}

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

Upvotes: 4

Roel

Reputation: 19622

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)

Upvotes: 8

ChrisBD

Reputation: 9209

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.

Upvotes: 2

Gerald

Reputation: 23489

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.

Upvotes: 11

SmacL

Reputation: 22922

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.

Upvotes: 2

Rob

Reputation: 26324

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

Upvotes: 7

Gishu

Reputation: 136613

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.

Upvotes: 3

KPexEA

Reputation: 16778

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/

Upvotes: 1

Pontus Gagge

Reputation: 17258

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.

Upvotes: 2

Mark Ingram

Reputation: 73625

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.

Upvotes: 3

Corey Trager

Reputation: 23123

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.

Upvotes: 9

Einar

Reputation: 3317

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.

Upvotes: 5

Joel Coehoorn

Reputation: 415790

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.

Upvotes: 9

Is There Still A Case For MFC

Answers (14)

Related Questions