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.

Chrystal

If the decision is between Win32 and .Net... go .Net Several people are complaining about not having .Net for their platform... but if you were writing for Win32 this cross platform isn't an issue. – Eggnog

I still regularly develop in c++ win32 - including brand new applications. Most of our programs are graphical in nature with very few stock UI functions. I find people who curse non-managed memory just are often just repeating what they have heard, and not actually experienced in c++. I prefer to be "closer to the hardware" in order to optimize certain algorithms. Also, I will correct one big misconception - the learning curve for win32 is LESS than .NET and C# (given you are experienced in c++). See - charlespetzold.com/pw5/index.html. +win32 installs/runs easily all win vers. – Jackstay

Sorry, but I rarely see .NET apps in action. Most of the Windows programs today are written in Win32API/MFC/Delphi/C++Builder/wxWidget/Qt. – Rover

Answer 1

• 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.

Hiram

Answer 2

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.

Rainproof

I wish I could up-vote this more times. When I want to try a new app and it asks me to install a runtime I don't have already installed, I immediately try something else. – Parasympathetic

How often do you install a new version of .NET runtime or the JRE? I think that I installed .NET 3.5SP1 back in August 2008. – Puleo

Olli: You are a developer, which makes you the elite of computer userrs. Unless your customers are also developers (and especially if they are unexperienced users who barely use their computer), about half of them will probably not have the runtime installed. – Rainproof

One could bootstrap the framework - but that turns your 2mb app into a 20mb app. The upside is that the user isn't aware that they're installing the framework. – Oates

As I user I would want the installer to download and install the framework for me if necessary so that the original download is not bloated with the framework. This way I can download the application faster if I already have the framework. Still, it's far from perfect. A native application is definitely better here. – Rainproof

Sometimes I need to write a small tool with an intention to make it executable on at most machine as possible. I tend to use C++ for this. When .NET came out I hoped that using the lowest .NET version will be good strategy for such tools but it is definitely NOT - .NET 1.0/1.1 is archaic, and .NET 2.0 is not installed by default on new versions of Windows. Finally I'm sure that C++ is the best choice but sometimes I choose .NET 3.5 out of plain laziness when particular tool is easier to write in .NET (and I know the price - harder or not possible to use on older machines). – Summary

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.

Bignoniaceous

Answer 4

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.

Puleo

Nothing could be farther from the truth. The performance penalty of running is a managed environment is huge. You have little or no control over how memory is managed this is a disaster for apps that need Real Time performance like video games. Managed solutions are usually best for business apps. – Currie

And you are stuck with a windows only solution. Too bad for all those Mac users... – Pitiful

Granted Unmanaged C++ does not make sense for every situation. But it does still have its advantages in certain scenarios per the intention of the original question. You would think from all these comments that Unmanaged C++ has no place anymore (not true). – Currie

There are alternatives to .Net that are cross platform and still managed (e.g. Mono, Java). – Hesychast

@James, granted C++ has its place for video codecs, video games and real time scenarios. But definitely not for desktop apps, web apps, business apps and so forth. – Puleo

@wdu, writing a native C/C++ app that is portable is black art. It requires a lot of effort. Achieving the same with mono/.NET and Java is easier. – Puleo

This answer has a number of good points, but I accepted James Atkinson's answer because it more directly answers the question. What I really wanted to know was "what place does unmanaged C++ still have a .NET world". – Chrystal

I agree with James. The memory overhead for .net apps is massive. Look at Qt (now with LGPL) for a good unmanaged cross-platform solution. – Pamulapan

Again, I cannot disagree more on that point. Yes, there is an overhead due to GC, but on modern PCs with ~4GB of RAM it's just pointless to talk about memory issues in standard desktop apps. Memory handling in unmanaged code is error prone and costs time and thus money. – Puleo

You guys that are saving managed code can't handle games really need to check out XNA. True 3D games in Java suck but XNA is amazing and easy to work with. – Eggnog

Answer 5

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

Spindle

.NET tends to "hog" memory and not release it back to the OS unless the latter's available memory falls below a threshold. 'Tis OK if your there will be few instances of your app running concurrently, using most of the resources for it. In other situations, it's a disaster. – Parasympathetic

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++.

Larceny

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.

Witch

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.

Currie

Comparing apples to bananas. C++ is a multi-platform language, which can be used to create code targeting the .NET environment. This app would be as easily decompiled as a c#/CLR or Java/JVM one. And then, if I recall it correctly, GCC can compile java to native code, so this point is moot. – Parasympathetic

Actually it's not moot at all, it all depends on which compiler you use. You're point is true if the code is compiled to managed code. But if you compile to unmanged code then my point still stands. – Currie

It's hardly a protection the obfuscation techniques for managed code are weak by comparison. Have you ever tried to disassemble native code back into working C++? Trust me, it is infinitely harder to do than to reverse engineer a managed app where there is any free tools that do this now. – Currie

I wish I could edit my comment. I meant to say there are many free tools that do this now. So there definitely is an advantage if you want to write something that has stronger code protection. – Currie

Answer 9

.Net programs also have a support lifetime, where native do not really. Native will run for many years across different OS's without requiring updates.

.Net programs can be hosed by bad .Net configuration, native just keeps on running and is hardly effected by OS updates.

.Net programs startup slow and feel sluggish, native starts quick and runs quick.

.Net has to be coded for lowest common denominator (most distributed framework version), Native compiles all code into application - so use what you want.

Use Delphi for Native, not C++. .Net is partially based on Delphi RAD and Java backend.

Malediction