• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Some questions about MFC

Sureshot324

Diamond Member
Is MFC a worthwhile skill to learn in todays and the future's job market? I know the trend for making Windows GUI Apps is .Net and Java, but I prefer native apps that don't run on a virtual machine. Do most native Windows Gui apps use MFC? If not, what are the alternatives?
 
AFAIK the alternatives are pure Win32 or a 3rd party library like wxWindows, GTK or QT. But frankly just about everyone has the .Net runtime installed these days so I don't see a reason not to use Windows.Forms and save yourself a ton of hassle and as a bonus you've got a good chance of your app running on other OSes via Mono.
 
What kind of work do you want to do, and for whom?

Most corporate development for in-house applications has shifted to .NET, and a fair amount of end-user/shrink wrap development as well. The tools / components / libraries being developed are also .NET first, MFC second (often without as many new features).

The JIT compiler is good enough for almost all applications, so for new development there uusally isn't any reason to prefer MFC.

We still use VC++ 6 / MFC at work, mostly because we have a large existing code base that would not gain anything from being re-written.
 
The way things are working these days is that all new development (on Windows) for the most part is .NET-based. There's really no good reason for it not to be given all of the advantages it has over native Win32 or MFC. But like DaveSimmons mentioned, there is a TON of legacy stuff out there that uses MFC and it's not going away anytime soon.

Obviously the more skills you have the better, but if you want to develop the new stuff, .NET is the way to go. Actually, let me rephrase a little. If you want any kind of future in Windows programming and are just starting out, learn .NET. There is really no option here. Your only option is whether you want to learn both MFC and .NET which never hurt anybody.

And of course all this comes with a caveat. If you're writing some super-critical performance oriented app and need to drop into assembly to get things done, sure consider Win32 but if you're writing normal apps like the rest of us, go .NET.

Oh and don't forget about those web technologies. You've got to stay on top of the industry.
 
As others have said MFC has basically been phased out (Windows Forms was designed as a replacement), so it is useful for legacy apps (like COBOL 😉) but not necessarily something worth learning at this point (and certainly not worth learning over .net or java).
 
From a purely educational standpoint, I had my C++ students learn MFC simply because it helps them understand what .net does to simplify programming...
 
Originally posted by: sao123
From a purely educational standpoint, I had my C++ students learn MFC simply because it helps them understand what .net does to simplify programming...
Then they miss out on how MFC simplied Windows programming from the raw Win32APIs

The more protected people get can also make it harder to break out of the cookie cutter mold and find out why a problem exists. 🙁

 
Originally posted by: EagleKeeper
Originally posted by: sao123
From a purely educational standpoint, I had my C++ students learn MFC simply because it helps them understand what .net does to simplify programming...
Then they miss out on how MFC simplied Windows programming from the raw Win32APIs

The more protected people get can also make it harder to break out of the cookie cutter mold and find out why a problem exists. 🙁

Yes, but it's unavoidable. We can't move forward very much longer programming systems at our old levels of abstraction. In the future it will be even more so, with layers of interpretation between the machine and whatever language we use to state our intent.
 
Originally posted by: Sureshot324
What do most freeware/open source apps use for a Windows GUI API? I have a feeling it's not .net or java.

My feeling is that most of that stuff was developed in Visual C++ 6.0
 
Originally posted by: postmortemIA
Originally posted by: Sureshot324
What do most freeware/open source apps use for a Windows GUI API? I have a feeling it's not .net or java.

My feeling is that most of that stuff was developed in Visual C++ 6.0

Meaning they used MFC?
 
Originally posted by: Sureshot324
Originally posted by: postmortemIA
Originally posted by: Sureshot324
What do most freeware/open source apps use for a Windows GUI API? I have a feeling it's not .net or java.

My feeling is that most of that stuff was developed in Visual C++ 6.0

Meaning they used MFC?

Probably, or something like straight WINAPI, or other frameworks like WTL/QT/GTK/custom ones. Even today I don't think there are too many non-inhouse apps written for .NET. I also get the impression that a lot of freeware apps are written in Delphi. Although I'm sure you'll be seeing more and more .NET-based freeware apps.
 
Visual Basic 6 was also very popular for freeware and shareware, since it was easy for hobbyists to start using and the IDE is designed around drag-and-drop user interface creation.
 
Originally posted by: dighn
Originally posted by: Sureshot324
Originally posted by: postmortemIA
Originally posted by: Sureshot324
What do most freeware/open source apps use for a Windows GUI API? I have a feeling it's not .net or java.

My feeling is that most of that stuff was developed in Visual C++ 6.0

Meaning they used MFC?

Probably, or something like straight WINAPI, or other frameworks like WTL/QT/GTK/custom ones. Even today I don't think there are too many non-inhouse apps written for .NET. I also get the impression that a lot of freeware apps are written in Delphi. Although I'm sure you'll be seeing more and more .NET-based freeware apps.

I get that feeling too. Since .NET runs on a virtual machine, it will always be slower and more resource intensive than native code. It just seems cheap for a company to charge you good money for an application, and then save a few bucks by writing the program for .NET instead of native code. I'm guessing most commercial software will use MFC for a while yet.
 
It just seems cheap for a company to charge you good money for an application, and then save a few bucks by writing the program for .NET instead of native code. I'm guessing most commercial software will use MFC for a while yet.

With as fast as machines are these days the difference is hardly noticeable to the user. So why should a developer waste his time using crap like MFC when the tradeoff is a huge loss for both parties? I'm not saying that a lot of places won't stick to MFC or whatever toolkit they were using before but the reasoning will almost always be that they don't want to spend the time rewriting the project in another language and not that they feel reusing things from .Net would be cheating. Infact most commercial software places would probably rather cheat, save some money and charge the same prices than not.
 
Back
Top