What advantages are there to developing a Win32 app in C++ over a .NET app in C#?

Question

I learned windows programming using Visual C++, and the Win32 API. Nowadays, it seems most apps are being developed in .NET using C#. I understand that most of the time there isn't much performance difference between native code and managed code. So I'm wondering, if I were to start writing a new desktop app today, is there any reason (other than the fact that I'm more familiar with C++), that I might want to write it in non-managed C++ instead of .NET? Are there still some advantages to using C++ and native code? Or has that method been more-or-less replaced with .NET on the Windows platform?

Of course I know that people who are writing low-level device drivers and similar programs wouldn't do it in .NET. I'm asking with reference to typical client-facing apps that don't make direct hardware calls.

Answer 1

Memory footprint. But unless you're developing for a severely handicapped machine memory-wise, it really shouldn't be an issue for most applications.

Answer 2

• Performance (certain situations, such as graphics)
• Memory footprint (as Mancuso said)
• Use of existing libraries
• No need for a runtime
• Finer control

To list a few.

However, you may also want to look at the question from the opposite angle to fairly evaluate which language to use.

Additionally, you could use C++/CLI to incorporate both native and .net code.

Answer 3

If your application needs to be able to run without an installation (i.e. if you can't or shouldn't do something like install the .NET framework), you can't count on .NET being on a windows machine (pre-Vista). Lots of utility applications can fall in this category.

Answer 4

Given your parameters, no, I see no reason.

Answer 5

IMO the most important one for small downloadable applications is that native code does not need the .NET runtime. While broadband becomes more and more common not nearly everybody has it yet.

Some people may be disappointed to see that your 2 MB application actually requires another 20MB of framework download and a bothersome installation process to run. If they are not sure whether or not they really need your application in the first place, they might just delete it before even giving it a try and turn to a competing product.

Answer 6

If you can afford the dependency on the stack, go for .NET Modern, elegant, powerful and as a result much quicker to develop for.

But realize that you chain your app to it - to the language and the framework, if you forsee a future where you may want to escape this, then better think twice.

Win32 is old and clunky, but it works on virtually any Windows version without extra dependencies, and your code can be in plain, portable, C/C++.

Answer 7

+1 for not having to require a .NET package/install on the target machine(s). This is still a big issue.

When all machines have mono or NET it won't be such a big deal.

Answer 8

Two things that I can think of.

1. Protection of intellectual property. It's infinitely harder for someone to reverse engineer an Unmanaged C++ app. Managed .Net or Java apps can be easily de-compiled this is not the case with Unmanaged C++.

2. Speed. C++ is closer to hardware and has a smaller memory footprint as the other comment mentioned. This is why most video games continue to be written in C++ and inline assembly.

Answer 9

I would recommend to write every desktop application in managed code. .NET/C# is a great platform to do so.

My reasons:

1. Performance penalty is negligible. Google for benchmarks if you don't take my word. What matters more is the code itself. You can write O(n^m) algorithms in C++ or .NET/C#. JIT engines are very mature these days.
2. Unmanaged C++ has major drawbacks when it comes to unit testing, mocking and refactoring. It's very cumbersome and inflexible. Reflection allows managed code to make such things very convenient.
3. Deployment is a small issue. However, creating a setup which checks for the necessary .NET preconditions and installs them automatically is a no-brainer.
4. Compilation is quicker, no linker! It even happens in the background when you edit the code.
5. .NET library support is way better and cleaner than STL, MFC and boost.
6. No header files and macros. They are just error prone.
7. Security! Good bye buffer overflows, bad pointers, uninitialized variables...
8. Exceptions. Clear exception hierarchy in .NET. C++ exceptions are messed up.