How is WinForms programming in Visual C++/C# different from Windows programming in Visual C++(MFC)

Question

How is winforms programming in visual c++/c# different from windows programming in visual c++(MFC).

Also I want to know whether C# is strong enough to do Windows programming as in other than forms.

Answer 1

There are a few notable differences:

• You'll eventually be more productive as it is much easier to do (.net)
• The language helps you from making a lot of common mistakes (null pointers, overflows, leaks)
• The framework is a lot (and really I mean a lot) more clean than MFC
• In essence you can do almost anything. The least common 0.01% of things you need to do through direct win32 DLL invokes (or use a wrapper or library someone else made)

Answer 2

I'm not sure if anyone can give one single answer to this question, I can just try to point out a few of the many differences:

• C# and C++ are quite different: Memory management, package structure, class layout, events/delegates, generics/templates... Even writing non-GUI apps is completely different in C++ and C#. Many of the features of the C# language are very helpful if not even designed for GUI development.

• Winforms has a very good visual designer support if compared to MFC. For 95% of all apps, you'll be a lot more productive using winforms. This is especially true for custom controls (either your own or third party)

• MFC on the other side provides more framework support (document/view structure etc.).

• For some applications, MFC apps may seem more responsive. In most of these cases, a winform application can be optimized to have the same performance, but this is above the average winforms developer level (which is generally lower than the knowledge level of MFC programmers).

• MFC encapsulates the WIN32 API more directly than Winforms do. There are cases where you need to access the WIN32 API even from winforms directly. Then it is not always clear (and not well documented), how to do this. Again, a typical winforms programmer has less knowledge of the WIN32 API than a MFC programmer, so in these cases he will run into troubles more likely.

• I think winforms is well supported and you can solve pratically all GUI/NON-GUI tasks. For most tasks, it will be easier to write a C# program.

I'm sure, there are much more arguments pro/contra, I just noted the few that came into my mind...

Answer 3

As a professional, I have to admit that I prefer to use Delphi instead of C++ for any WIN32/Desktop development. If you're going to build GUI applications that are client applications or stand-alone applications then you might find that Delphi (and C++Builder) has far more visual components than .NET, at this moment. That's because .NET is still more popular for web development and service applications.

Doesn't mean that Delphi (or C++) is more powerful than .NET, since .NET is gaining quickly on the GUI application level. WPF/Silverlight is going to promise a lot of new possibilities for developers.

Another reason why many people are still using Delphi/C++ for WIN32 is because they still have lots of legacy code. And some of this code has already been working for over a decade and only needs additional maintenance. Rewriting those projects in C#/.NET would be way too expensive. People are considering this but existing code has proven itself already. New code will introduce new bugs.

With C# you're not going to do Windows development. You're doing .NET development and some parts of .NET will allow you to use the Windows functionality. However, a major part of the .NET classes are actually wrappers around the Windows API, making it easier to use those functions. But not everything is already implemented in .NET, so there's still a lot of work that needs to be done.

The danger of .NET development is what I like to call, the ".NET Hell". When .NET was introduced, people said it was going to end the DLL Hell that was bothering every C++ developer on Windows. Well, It did end the DLL Hell, only to replace it with the .NET Hell, where multiple versions of the same assembly are still able to cause lots of problems. So, in that regard, nothing much has changed. You're still depending on a certain runtime version of a specific library (especially with third-party libraries) so there's no real gain here.

Still, I really like .NET development, most of all because more and more applications are run as a service (SAAS) instead of the old-fashioned desktop application. Basically, you'd only need a web browser to use those applications, thus becoming less dependent on certain hardware requirements. Here lies the real strength of .NET development.