"Nobody should be using MFC any more" Why?

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

And why开发者_如何学Python is that?

---

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.

---

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.

---

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

---

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.

---

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.

---

If you watch the Project Centennial talk from Build 2015 it shows Adobe still using MFC in their Adobe products. They are using mfc100 from VS2010 to make a UWP app from Win32/COM/MFC components, so MFC is still being used.

Until Microsoft provide a C++ UI Framework with the UI elements that desktop apps use Ribbons/ToolBar/Menus/Dialog etc, then MFC might still remain popular even with all its quirky bits.