MFC vs. .net

[walter clark]

From the point of view of a command line programmer (whose been at it for 25 years) what is the difference between MFC and .net?

[Narue]

MFC is a library of classes that wrap the Win32 API and make it more convenient to write applications. The .NET framework is a more complete abstraction into a managed environment (rather than a wrapper for a lower level API).

[walter clark]

Thank you Naru, for your reply.
I understand that .net generates managed code which is a safer intermediate code that another program reads before going to the operating system.
And that MFC is much older.
But what about from the programmers point of view. Is there any reason to choose the the MFC wizard option over the newer .net option? How about from the point of view of "easier to code?"

[Narue]

>But what about from the programmers point of view.
If you want to use standard C++ without Microsoft's C++/CLI dialect, you're stuck with MFC. If you want to use .NET, C# is probably the easier option as the language was designed with .NET in mind. C++/CLI has the .NET stuff stapled onto an existing language in a somewhat inconvenient way (though it was surprisingly well done).

There are so many pros and cons that it's hard to list them all, unfortunately. If you want "easier to code", .NET is by far the better option in my opinion. I'd rather write straight Win32 code than MFC.

[walter clark]

Thank you again Narue.
C# sounds like what to direct beginners to.
But how about someone who has hundreds of C and C++ programs? I rarely start new. I always re-use (image processing stuff) previous stuff. I like the IDE of Visual C++ but I still find myself clicking on "Console Application". Your advice and that of others seems to be .NET (CLR) but what about the speed of doing the image part? Is that burdened by any of the .NET stuff?
Walt

[Narue]

>C# sounds like what to direct beginners to.
C# is where I direct everyone who wants to program .NET. There's nothing wrong with C++/CLI, but it's not as clean as C# for working with .NET. Further, C++/CLI is less portable than C#. For example, Mono doesn't provide a C++/CLI compiler.

>what about the speed of doing the image part? Is that burdened by any of the .NET stuff?
It depends on what you're doing and how you're doing it. But if you've only worked with "console" programs up until now, I don't suspect the image processing is going to be your biggest concern when diving into non-"console" projects.

[Stinomus]

If you want portability or the ability to easily port between managed and unmanaged code then C++/CLI will provide the least effort. .Net is language-independent as everything gets compiled to an intermediate language first so you can use it's features through whichever .Net language you choose and you'll find a LOT of really neat features that will assist you in solving just about any programming problem.

If you need the speed of a native implementation you can marshal your data structures once your processing is complete, there isn't generally too much overhead in doing it this way but as is the same with utilising the JNI, it really does depend highly on the implementation as to which method is best - native + marshalling or just doing it in the managed language.