Udostępnij za pośrednictwem

MFC is not dead

  • Artykuł

When I wrote my master's thesis was the first time I came in to contact with VC++ and MFC. I worked with MFC and VC++ quite a lot for a number of years but the last four or five years have not had much MFC work in it. When the .Net framework came along with the possibility to write managed C++ applications I thought MFC was dead and didn't give it much more thought.

Then I read about the new VC++2008 feature pack here and watched the channel 9 video referenced. I noticed how the reporter also questions the MFC developer about the presumed death of MFC. Apparently MFC is not dead as many, including me, thought. The reason I thought so was that I just assumed that with managed C++ no one would bother writing them unmanaged in MFC any more. But when I think a little more about it I guess there are lots of people still out there who are familiar with the MFC framework and who do not have the time and/or interest to learn the new managed equivalents.

Some might say that you want to write MFC applications in stead of managed ones because the users do not have the .Net framework installed. A fair point but frankly I do not think that the user that will benefit from this MFC update (which for example includes office ribbon support for office 2007) also already have the .Net framework installed.

Update: I noticed that this post was referenced by this one: https://blog.stevienova.com/2008/04/12/why-is-mfc-not-dead/. I realized I was not 100% clear in my post. I must say that I agree with the author of that post - MFC will be used for many years for the reasons mentioned: People want to make applications that work across many different versions of Windows without installing the .Net framework. There was never a doubt in my mind that was the case. However I was surprised there was so much new development put into new versions of MFC since I guess all the new stuff will not work very well anyway. And much of the new stuff in MFC is there to mimic stuff seen in the managed framework and/or in latest versions of office/windows. And if you run Vista or Server 2008 I guess you will have the .net framework already installed and hence do not need to use MFC.

Comments

  • Anonymous
    April 12, 2008
    Just as COBOL is with us, so will MFC endure.

  • Anonymous
    April 12, 2008
    Very true...

  • Anonymous
    April 12, 2008
    Managed C++ isn't a IMHO good replacement for a native framework like MFC, because beside the deployment issues

  1. Managed C++ was ugly and has later been replaced by C++/CLI
  2. Dealing with native code from managed C++ or C++/CLI    is still not that simple as from a native framework, because    you permanently have to marshal data from managed    to native code and vice versa
  3. Many C++ developers don't want to touch managed code,    because managed code is meant to be slow and ineffective,    although it's not (generally speaking).    Additionally most think they lose control over the    memory management. Anyways, I think the deployment issue is the main problem, why MFC is still preferred. There are tools which compile managed applications to native code, including the code of the .NET framework and make it possible to ship the managed application without any binding to the .NET framework but they are expensive and the emitted code is much bigger in size than the equivalent native code. I think it would be great if Microsoft could provide an effective IL to native compiler, which would allow to compile managed applications including the framework code directly to native code. I know there are downsides regarding security / patching etc, but with some intelligent bindings, the "native" compiled managed applications could be patched automatically too.   As for me, I don't want to touch MFC for new projects again, after I got used to the productivity boost of other RAD frameworks, like WinForms
  • Anonymous
    April 12, 2008
    I think the deployment issue is the main problem, why WinForms isn't accepted widely by C++ developers. There are other issues:
  1. Marshaling
  2. GC, many C++ developers want to control memory    by their own. At least they think they can.
  3. Managed C++ was ugly, though that isn't an issue    anymore
  4. Managed code is meant to be way more slower
  5. RAD experience with C++/CLI isn't that good    as in other managed languages    (code formatting, everything in a header file etc.) There are already tools which compile managed code to native code, including the .NET framework. But the resulting code is IMHO quite large in size, compared to the native equivalents. It would be great if Microsoft could provide an effective native compiler, which solves the deployment issue or as an alternative allow to bind needed parts of the framework to an application and ship them with an application, as a kind of resource dll, which isn't used if the complete .NET framework isn't installed. I know there are (many) downsides to this approach, but this would increase acceptance of the .NET framework a lot. Vista ships with .NET preinstalled, but the deployment issue won't be solved, since there will be always new versions of the .NET framework. As for me I simply can't go back (for new projects) to MFC after I got used to the huge productivity boost of other RAD frameworks. MFC isn't that bad at all, but I think I'm more productive using C# and WinForms or other native C++ RAD frameworks.

  • Anonymous
    June 17, 2008
    Remember there are many legacy applications on the market. We cannot rewrite a whole application to use .NET, that would be too expensive, but we can give the application an updated look by using the new MFC feature pack. For new development I think most will go the .NET way. For legacy applications the feature pack is great news.

  • Anonymous
    December 13, 2011
    The comment has been removed

  • Anonymous
    December 15, 2011
    The comment has been removed