If you were to use "straight C++" (or C), you''d have to access the Win32 API directly. What MFC does for you is to hide all of the Win32 API''s complexity, wrapping it all into classes, macros, and millions of other things. With an MFC program you no longer see or deal with the message pump code, nor do you process WM_* messages directly. Instead, you use methods. Subclassing controls is very easy with MFC. Also, the ClassWizard is hard-wired for MFC, and you can do some serious framework coding just by clicking.

Now, why use MFC? Well, I tend to think that MFC is too bloated--and just simply not necessary--for a game...at least anything real-time. If you want to write a Windows game, just use the API directly. For a game you only need a trivial amount of actual API code, and using MFC is just more of a headache than it''s worth. I''d suggest using MFC for any kind of editor you might need to make, from medium to large scale. I think that using using the API in C is the best way to go for small projects.

Personally, I think MFC is just a pain in the bottom, in most cases, but that may be just me. =)

I hope all that helped.

MFC is industry standard for writing business apps and other non-DirectX/GL/whatver programs. That is a lot of level editors, tile builders, etc. use MFC. If you want a job doing standard programming MFC is good to have on your resume.

That being said, I''ve found programming standard windows programs a lot easier and less buggy using VCL in C++ Builder or Delphi from Borland. Moving from MFC to VCL was pure bliss.

I too like to use MCF when doing Windows applications that uses, dialogs, buttons, menus etc. I don''t like the code classwizard generates though. It''s messy and hard to read, in my opinion.

I don''t like MFC and I don''t use it at all. When I code some kind of editor, such as level editor or windows application that uses menus, dialogs etc. I use Borland Delphi.
Delphi is cool!