MFC vs .NET
Printed From: Codejock Forums
Category: Codejock Products
Forum Name: General Discussion
Forum Description: Topics Related to Visual C++ MFC Development in General
URL: http://forum.codejock.com/forum_posts.asp?TID=8669
Printed Date: 27 September 2024 at 9:55am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: MFC vs .NET
Posted By: znakeeye
Subject: MFC vs .NET
Date Posted: 05 November 2007 at 11:39am
|
Ok, try to be as unbiased as possible! We are going to compare MFC and .NET.
I know many elite programmers still prefer MFC over .NET (I know I do). Still, I sense it might be time to emigrate.
I'm involved in a project with 600k lines of 10 years old MFC-code. With GoF fresh in mind it is hard not to eager for a complete re-design. Especially since this is a project with a bright future.
Here's my dilemma. What should we do?
1) Rewrite all code in modern C++ with STL/Boost, together with Xtreme ToolkitPro for the GUI.
2) Emigrate to C#/.NET and use Xtreme SuitePro for some fancy GUI.
3) Other ideas?
|
Replies:
Posted By: sserge
Date Posted: 05 November 2007 at 5:04pm
|
4) start migrating your business logic to pure C# (framework 2.0 and above) and wait a few months until native .NET GUI controls from Codejock will be released... |
Posted By: znakeeye
Date Posted: 06 November 2007 at 2:34am
| Sounds reasonable, but can you motivate it? :) |
Posted By: ABuenger
Date Posted: 06 November 2007 at 7:16am
Realistically, anything else but a step-by-step refactoring will fail. There is a good article on Joel on Software: "They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch." http://www.joelonsoftware.com/articles/fog0000000069.html - http://www.joelonsoftware.com/articles/fog0000000069.html An other interesting article: http://www.joelonsoftware.com/articles/fog0000000339.html - http://www.joelonsoftware.com/articles/fog0000000339.html Keep that in mind. For my (privately developed freeware) app I'll start to integrate .NET components into an MFC app (But only because there are no shiny MFC gauge controls). I've separated the logic from the UI before. If you've done that it's not a big deal to put a new UI on your app. But unfortunately almost every MFC app I've seen in this century does not separate the logic from the UI. Most of the logic is in the view or dialog code and is bound to some controls. ------------- Codejock support |
znakeeye wrote:Posted By: apuhjee
Date Posted: 06 February 2008 at 12:58pm
I wish I had the time to elaborate on some details, but I can say briefly from personal experience that a .NET solution will offer benefits in several key areas of development, including:
Also, Microsoft http://msdn2.microsoft.com/en-us/practices/default.aspx - patterns & practices offers a wealth of enterprise development patterns, if that's your cup of tea... the highlight for us being the http://www.codeplex.com/entlib - Enterprise Library . Cheers ~ jp |
Posted By: rdhd
Date Posted: 11 April 2008 at 3:40pm
|
My only thought is to stay away from COM interop! Those RCWs just hate to release your COM interface.
Either use .NET to the max or not. Mixing the two can be quite frustrating. If you do mix them, then this is your best friend:
GC.Collect(GC.MaxGeneration);
GR.WaitForPendingFinalizers();
GC.Collect(GC.MaxGeneration);
The other good friend is System.Marshal.ReleaseComObject() but constant GC takes away the pain of knowing just how many times you need to call ReleaseComObject (one call is almost never enough).
We run the GC code above everytime we are about to shut down the app or a document. Failure to do so can mean that when .NET decides to run GC and the RCWs that get collected call Release(), there may not be any object in memory (kaboom). The alternative is to wait for each object's final release, which may never occur until shutdown since GC runs when MS decides it does. If your documents contain as much data as ours, its totally impractical to wait for GC to recover your memory when the final release call comes.
|
Posted By: MikeVance
Date Posted: 19 October 2008 at 11:10am
|
MFC is amazing only for applications that need MAXIMUM ZIP, such as sexy best-of-the-best Photoshop-style apps. All others should be coded in either C#/VB/Delphi -- anything but MFC, due to the productivity penalty. I respect MFC for its leanness and tight message pump, but that is it.
Offhand, I would say avoid a complete rewrite and transition your app over to DotNet gradually using C++/CLI, using your existing code as much as possible. Do not drive yourself insane by attempting a complete rewrite; if you do that then everybody will hate you, including yourself.
|