views:

410

answers:

5

Is it true that "Nobody should be using MFC any more"

And why is that?

+3  A: 

It is just an older technology: there are newer, shinier technologies out there that are far easier to use...

clownbaby
I wish you could use those "shinier" technologies with native code ... I'd take them up like a shot ... *sigh*
Goz
+1 for far easier to use (and maintain). I'd rather see C# code than MFC code.
Jason Berkan
+6  A: 

Arguably, no-one should ever have used MFC (speaking as someone who has been exposed to it since MFC 1.0). There were always better technologies around for GUI development, from Gupta's SQLWindows and Borland's Delphi to Microsoft's very own Visual Basic. And nowadays we have .NET or, perhaps more MFC-like, Qt.

MFC itself was a series of hacks,and often wilful misuses of the C++ language. Of course, if you have a big MFC project, you are probably stuck with it.

anon
MFC is the devils work.
jkp
It's not that bad. It works in a pretty solid fashion. Sure it's quirky but most people seem to hate it because "it uses macros", which is a poor argument.
John
@John: Sounds like C++ in general to me ;-)
Joey
Exactly. Lots of people want their frameworks to be some beautiful OO masterpiece, but forget C++ is not a beautiful language in that way.
John
Well, you can write quite attractive code in C++ (I agree a lot of people don't), but it is not a great language for creating GUIs, IMHO.
anon
Well thought out and stable macros à la boost metaprogramming can be OK, if complex. I save my hatred for its leaky wrapping of Win32 API's, its everything-and-the-kitchen-sink classes (think CString) and its lack of design not least for subclassing (you never know what will work unless you are well aware of each class internals and the Win32 API to boot). Of course, the maturity in the C++ community was less in the days, but even then, the MFC creators were well behind the curve.
Pontus Gagge
+1  A: 

It's slightly hard to see a good reason why a new project would use MFC/C++ ... unless it is the technology a dev team knows. A team experienced in C++ & MFC who jumps wholesale into .NET/WPF on a new project is going to lose a lot of time.

Joel wrote a good article on this way back (I think), but I can't find it. Basically, you need a business reason to switch technology. "It's old and ugly and we want to be cool with WPF" is not a business reason.

John
It is in a developers best interest to keep up with current technologies / frameworks. Especially those that are industry accepted.
clownbaby
John
It's in _a_ developer's interest. But that's not the same as a company who has a team of seasoned C++/MFC developers. It makes sense for them to stick with what they know until they can get their people trained up with something newer.
John
+1  A: 

Some days I feel a little like Paul Bunyan in the sense that I'm swinging my MFC Ax and taking down lots of trees only to see those new fangled chainsaws show up. Everyone says how much better the chainsaw is, so i learn to use the chainsaw and I start cutting down those trees, and then the feller-buncher shows up, and everyone says how much better the feller-buncher is, so i learn to use the feller-buncher and I cut down more trees.

I'm not saying the AX is better than the feller-buncher - its not - but if you already own the ax, and you already know how to use the ax, and all you need to do is cut down a tree...

Sometimes the devil you know is better than the one you don't.

FWIW - just about the entire Windows SDK is predicated on a macro; its almost like #ifdef and #define are an entire development language in of itself.

Ruddy
+3  A: 

No, it is not true. Statements like that are always wrong, because for every project and every situation you have to evaluate the libraries and languages again. And simply discarding MFC for no good reason is wrong.

Even though MFC has been around for years and a lot of people don't want to use it anymore for new projects, it still can be the best choice depending on the project. Yes, .NET and it's UI libs are in most situations the better choice for new projects today. But if you want a small memory footprint, very fast startup time or your app has to run on very limited computers, MFC still can be a good choice.

For example, Netbooks (or whatever you want to call them) are popular, and not all of them have the .NET framework installed. And those who only have 512MB-1GB RAM, you might not want your app to use that framework.

And of course, there are other non-.NET libraries besides MFC you could use. But MFC is still a good choice.

Stefan