Will VC++ MFC become obsolete in near future? [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 9 years ago.

开发者_StackOverflow Improve this question

Normally people say MFC is little clumsy. It makes UI development slightly difficult to maintain since it has lot of auto generated code. It has good architecture (doc/view) but is not transparent like Win32 programming to understand how window program works in the background. So with this situation, is it good to extend the exposure on MFC programming or better to switch to .NET since for faster UI design with ease in maintenance.

Is it good to continue as MFC developer or good to know .NET as well?

How globally companies are looking into MFC as a technology for UI developments. Are they comfortable in supporting their developers to continue with MFC or looking for changing their development technology.

I sincerely doubt that any company will start a new project using MFC instead of, at least, WinForms.

But I might just be too optimistic.

On the other hand, having someone that can maintain old projects that use MFC is always a nice-to-have, but I wouldn't rely only on that skill.

Well, our product consists of about 70 MFC-projects (EXEs and DLLs), with some 100 man-years of development effort.

We have to ensure that this application will be running in at least 10 years from now. And we have to ensure that our existing customers can use their NT-networks and Win98 clients.

With that in mind we still begin new projects using MFC.

Altough some optical stuff comes new with every Windows-version, the core of Windows is still pretty much the same and MFC will continue to work.

MFC already falls into the category of legacy code for most cases. BUT, teams/companies who only know C++/MFC will continue to use it for new applications because it's quicker for them, and lets them re-use existing code-bases.

So in conclusion, the proportion of MFC code which is legacy will continue to grow, but technologies normally take years or decades to die out, since the life-cycle of a team can be of this duration.

If you are an MFC developer, finding a way to learn .NET is definitely a good idea because fewer and fewer jobs will want MFC, and those will generally be old projects rather than exciting new stuff.

But it's still a useful skill, knowing some rare technologies can get you good money!

Keep your C++ skills up to date. If I'm interviewing candidates for a job and one knows C++ and can demonstrate some deep C++ skills I know that they'll be able to handle anything I throw at them, whether that's VB, C#, Java, Python etc. It's just slightly different syntax and semantics. Multi-threaded programming is an additional layer on top of that that's really nice to have.

I have done a lot of MFC over the years and still like it a lot. It's the easiest and fastest way to generate a small dependency free windows executable. I usually mix in ATL, STL and boost classes with MFC, they all work together as a happy family. You do need to understand what the auto-generated codes does, but really its not that hard, especially if you've done pure win32 programs.

Any MFC programmer should also learn .Net. It won't be hard because an MFC/Win32 developer will understand what all those classes in the .Net framework are actually doing.

As a career decision I would still encourage anyone to expand their skill set beyond just Windows desktop applications. For sure any consumer desktop application will want to be cross platform, as will many new business applications. If you want to stay with local computer applications you should consider learning a cross platform framework such as Qt.

Of course many apps are moving to the web, so it won't hurt a bit have some skills there also.