5

I am a big fan of Microsoft Technologies. Learned lot of .NET Framework and C# like programming languages. But I believe .NET applications are running on top of .NET Framework so They have some kind of slow. Then I heard about MFC a wrapper classes for Windows Development and It is standard for Commercial Application Development(I mean not business level application) so I want to know is it worth to learn MFC now? Is there any alternatives? I want to develop commercial level application Thanks for read my question.

unique
  • 5,442
  • 6
  • 23
  • 26
  • 11
    It's useful if you are employed somewhere that uses MFC. Otherwise, it's totally irrelevant. You'd be better learning about the raw Win32 API and how MFC/WinForms/WPF wrap around (or don't wrap around) it. – ta.speot.is Sep 22 '13 at 11:41
  • @ta.speot.is Thanks for your comment No, I have idea about develop commercial application as freelancer developer – unique Sep 22 '13 at 11:43
  • @KerrekSB I could not understand what you said – unique Sep 22 '13 at 11:45
  • 2
    I guess @KerrekSB was joking on the likely future of Windows8. Betamax and Laserdisc were two hyped technologies of the past that never lifted off. – LorenzoDonati4Ukraine-OnStrike Sep 22 '13 at 11:57
  • Would say that this is opinion based. – user2672165 Sep 22 '13 at 12:08
  • Any More Suggestions.....?? – unique Sep 24 '13 at 05:46
  • 1
    @unique I'm late to the party here, but just wanted to point out that benchmarks have demonstrated that C++ is not that much faster than .NET. In fact, .NET performs faster with some data structures. The JIT compilation is so insanely fast these days. I will grant you that WPF is a bit slow. But WPF is awesome!!! – onefootswill Oct 19 '14 at 10:16
  • @onefootswill Thanks for your comment.Yes Nowadays we have precompilation to native code like options helps to gain more performance to the .NET Framework – unique Oct 20 '14 at 12:00

2 Answers2

15

No, I wouldn't learn it - I'd look into it to gain an insight into some of the ways the GUI classes work so you have a wider understanding of this old, but important, technology. But I would not learn it as a technology you want to create new GUIs into the future. Forget the non-GUI parts of MFC, only people who are big fans of Microsoft technologies used them, everyone else used much better libraries...

Although you can write great applications using it, TortoiseSVN for example, today using Winforms is much easier and gives you the same results. Yes, .net is slower than native code but for a GUI you're generally limited by the speed a human can react to changes, so a 'slow' system is still going to be ok, unless it gets so slow it is noticeably laggy or slow to respond. For this reason I'd skip WPF as I know too many support calls from myself and friends who all have complained about WPF's performance (there's also lots on the web about WPF being pretty poor).

there are alternatives, Qt is a great GUI tool. wxWidgets is good to, and also cross platform. Today the general attitude to GUIs are that they should be web-based, so you might be better advised to learn ASP.NET MVC 4 (not the older versions) as there appears to be a significant number of jobs for this technology today (tomorrow might be different!)

gbjbaanb
  • 51,617
  • 12
  • 104
  • 148
  • 2
    I'd agree with most of what you said. I would never agree that Qt is an alternative, though. There is no official support, unless you're going the digia-route, but then there's not 64bit build. It tends to get slow and the cross-platform support apparently made it near impossible to implement proper keyboard navigation. And then you have platform details crawl through the cracks every now and again. Plus, it lacks MFC's ability to seamlessly integrate with Windows Forms and WPF. – IInspectable Sep 22 '13 at 12:03
  • 1
    There is certainly a 64 bit windows build for Qt. I have been using it for 5+ years now on windows (and quite a few versions of Qt). Although now the officially package x64 dlls. – drescherjm Sep 22 '13 at 13:17
  • @drescherjm I should have worded this clearer: There is no [officially supported 64bit build of Qt](http://qt.digia.com/Product/Supported-Platforms/) (no XP/Vista and none of the embedded versions). The *Secondary Platforms* support includes the following statement: *"known errors in Secondary platforms may or may not be corrected prior to new version releases"*. I usually refer to this as *"unsupported"*. Depending on your project requirements and business regulations this poses a significant risk and precludes the use of Qt. – IInspectable Sep 22 '13 at 14:51
7

There's still shops who have a MFC codebase who cant just throw it away since its well tested projects and for those it can be useful but as a learning exercise it would be better to learn straight Win32 programming from which MFC and .NET still is derived.

From my experience: Guerilla games the makers of the PS3 Killzone series have tools in MFC Bosch security systems where I worked still use MFC Philips medical still has.

For new development they all use different technologies though.

Serve Laurijssen
  • 9,266
  • 5
  • 45
  • 98
  • Yep. New development is done with C# and/or .NET, MFC is old & was pretty absolutely horrible the one time I touched it. – Thomas W Sep 22 '13 at 11:50
  • 3
    @ThomasW Every complex framework will feel *"absolutely horrible"* if you don't take the time to properly learn it. Looking at your profile it appears you didn't know the Windows API or C++ either which is absolutely mandatory to understanding MFC. I'm working with MFC on a daily basis and while I cannot say that I'm in love with it I have to conclude: Everything else sucks even more. – IInspectable Sep 22 '13 at 12:11
  • @IInspectable so what is your idea about MFC? – unique Sep 22 '13 at 12:16
  • @IInspectable: _"... if you don't take the time to properly learn it..."_ time makes everything horrible. MFC needs very long time to learn and to use. Sometimes direct using Win32 APIs is simpler than MFC. – masoud Sep 22 '13 at 12:18
  • 2
    @unique If you need it, study it. If you don't, don't. If you are working on a team you'll know whether you need it or not. If you are a technical lead you should not discard it as *too old* or *horrible* lightly. It is, to date, the only native framework for Windows development with official support. – IInspectable Sep 22 '13 at 12:26
  • @IInspectable I want to learn it. Thank you for your comment :) – unique Sep 22 '13 at 12:33
  • @IInspectable -- I've used a variety of different frameworks (Delphi, Java, early MacOS, others). In contrast to those, the MFC didn't seem to give the slightest nod to checking valid state or reliability. Code attempts with it tended to just seg-fault or explode.. I understand it's the only OO wrapper/ library which doesn't require distribution of dot NET binaries, which is why we investigated it. But having tried it, gave me a new insight into how much better other frameworks did their job. – Thomas W Sep 22 '13 at 23:21
  • 1
    @ThomasW You failed to learn the basics. An intimate understanding of the Windows API is absolutely positively required to even stand a chance to understand the MFC. The dialogs you mistakenly thought were "seg-faults" are likely the debug assertions - state checking that MFC uses throughout (there are no seg-faults on Windows). It's certainly not the only native framework either, there's WTL, or wxWidgets. But it is the only one with official support. – IInspectable Sep 22 '13 at 23:26
  • 1
    @IInspectable Nope, the dialogs were the program crashing with a memory access violation exception (segfault being a quicker way of saying the same thing). See http://en.wikipedia.org/wiki/Segmentation_fault. High-level frameworks should simplify & wrap the low-level.. if you have to know both levels intimately to use it, there is no logical advantage or purpose to the framework. No, there was no state checking -- I looked at the MFC source -- stuff just exploded. Very poor by comparison with many other frameworks.. You're drinking far too much of the MS koolaid. – Thomas W Sep 23 '13 at 02:04
  • 1
    @ThomasW You know what they say about bad workmen blaming their tools. Many shops have rock-solid stable, large MFC programs which is the reason its still used and (slightly) relevant today. – gbjbaanb Jun 09 '14 at 12:04
  • 1
    @gbjbaanb -- Sure. I've written high-reliability code in C, C++, Pascal, QNX and Java including multitasking & hardware integrations. My professional opinion of the MFC is poor, based on comparison to other (better) frameworks. That opinion is not going to change. I've already got bare-metal experience. To claim users should know the Win32 API inside out misses the point of a well-designed framework, and the theory that memory access violations were "asserts" is ludicrous. Perhaps a wider breadth of experience is needed in the Microsoft C++ Win32 community. – Thomas W Jun 12 '14 at 04:57
  • @ThomasW I agree other toolkits are better, but that does not suggest no-one can write a MFC program without it crashing all the time. Regardless of its quality, it does work. – gbjbaanb Jun 12 '14 at 05:46
  • 2
    @ThomasW I agree with you that MFC is not there to be your best friend. MS actually says that MFC is not meant to simplify the Win32 API but rather to give an OO architecture. It is *still* mandatory to understand the API to make a MFC program that won't fail under the weight of misconceptions. Higher level frameworks often try to make things easier by hiding stuff so the coder won't see what is going on. The whole point is that, MFC *will not hide* the Win32 API, so if you go berserk with MFC, it *WILL* segfault or crash, it's guaranteed. – Frederik.L Feb 16 '15 at 08:16