13

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.

nwalke
  • 3,170
  • 6
  • 35
  • 60
Akaanthan Ccoder
  • 2,159
  • 5
  • 21
  • 37
  • @kenny: If that is so, why should MS come up with MFC feature pack (advancement to MFC UI design) for VC9 (VS2008). So they have something to contribute towards MFC which shows their interest in supporting or extending support to MFC. – Akaanthan Ccoder Apr 08 '10 at 11:40
  • 2
    Because some significant customers that are important to them ask for it. That doesn't mean that it's not obsolete, IMO. – kenny Apr 08 '10 at 13:18
  • Thanks for the comments. If not MFC, then which according to you is best for UI design & development for windows in future. Anybody any views on that? – Akaanthan Ccoder Apr 09 '10 at 07:27
  • 1
    Well your only real choices are Winforms and WPF if you want something that really gets the most from Windows. And WPF is the current approved way, Winforms is already outdated on MS' roadmap and pushing Silverlight (related to WPF on their phone platform). Java can do UI as can wxWidgets, but I never saw a cross-platform solution that could touch a native Windows app for looking right. – Mr. Boy Apr 09 '10 at 08:32
  • Does Qt wrap all that's possible in the .net technologies? Or is it a "better MFC"... I never used it. – Mr. Boy Aug 12 '10 at 07:23

5 Answers5

9

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.

ereOn
  • 53,676
  • 39
  • 161
  • 238
  • 4
    Within a company that has a lot of experience using MFC and no record using C#, they will likely use MFC on new projects - examples like dwo's where companies develop new apps within an existing project are a big factor as well. – Mr. Boy Apr 09 '10 at 08:30
  • I can understand that a company don't want to (and can't) just throw out old softares just to rewrite them in a modern language/technology. On the other hand, developpers *should* try to be up-to-date regarding new technologies. If no-one does, what will happen in 50 years when only a few (expensive) people still know how to maintain the existing softwares ? – ereOn Apr 09 '10 at 11:51
7

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.

dwo
  • 3,576
  • 2
  • 22
  • 39
  • 1
    And I believe your situation is not an exception. The amount of MFC business applications out there and running at customer sites is huge. And in my experience the life time of a well integrated application is much longer than developers and customers usually expect. – Slauma Apr 08 '10 at 17:16
4

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!

Andrew Prock
  • 6,900
  • 6
  • 40
  • 60
Mr. Boy
  • 60,845
  • 93
  • 320
  • 589
2

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.

snowdude
  • 3,854
  • 1
  • 18
  • 27
0

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.

Jim In Texas
  • 1,524
  • 4
  • 20
  • 31