Wednesday, January 26, 2005

C# vs C++

Via Eric Gunnerson - one of the designers of C#. It's obviously biased, but he makes some points for C++ as well.

At the class a took a while back, the instructor asked me to talk a little bit about the benefits of C++ vs the benefits of C#, since I had worked in C++, then in C#, and now in C++ again.

I talked for about 5 minutes on why C# was better, in the following themes. Note that I'm speaking about the whole programming environment, not just the language.

Automatic memory management

There are several facets of this. When I read or write C++ code, I keep part of my attention on the algorithmic aspects of the code, and another part on the memory aspects of the code. In C#, I usually don't have to worry about the memory aspects. Further, in C++ I need to figure out who owns objects and who cleans them up, and also figure out how to clean up in the presence of error checking.


Without a lot of dedication, using return codes is a bug farm waiting to happen. In the C++ world, some functions return HRESULT, some return a bool, some return another set of status code, and some return a number and use an out-of-range value as an error indicator. Oh, and some are void. You not only have to write the correct code there, you have to successfully convert back and forth between the various kinds of error handling.

You also lose the opportunity to write more functional code. I end up writing something like:

CString name;

instead of writing:

string name = employee.FetchName();

And, of course, exceptions are fail-safe in that you get error reporting without doing anything, rather than having to do everything right to get error reporting.

Coherent libraries

The C++ code I'm writing uses at least 6 different libraries, all of which were written by different groups and have different philosophies in how you use them, how they're organized, how you handle errors, etc. Some are C libraries, some are C++ libraries that are pretty simple, some are C++ libraries that make heavy use of templates and/or other C++ features. They have various levels of docs, all the way from MSDN docs through "read the source" docs to "a single somewhat-outdated word doc".

I've said in the past that the biggest improvement in productivity with .NET comes from the coherent library structure. Sure, it doesn't cover everything in Win32, but for the stuff it does cover, it's often much much easier to use than the C++ alternative.

Compilation Model

C++ inherited the C compilation model, which was designed in a day when machine constraints were a whole lot tighter, and in those days, it made sense.

For today, however, separate compilation of files, separate header and source files, and linking slow things down quite a bit. The project that I'm working on now takes somewhere on the order of a minute to do a full build and link (that's to build both the output and my unit tests, which requires a redundant link). An analogous amount of C# code would take less than 5 seconds. Now, I can do an incremental make, but the dependency tracking on the build system I use isn't perfect, and this will sometimes get you into a bad state.


Reflection is a great feature, and enables doing a ton of things that are pretty hard to do in the C++ world. I've been using Source Insight recently, and while it's a pretty good IDE, it isn't able to fully parse templates, which means you don't get full autocompletion in that case.

Code == Component

In C#, you get a component automatically. In C++, you may have extra work to do - either with .IDL files or with setting up exports.

Language Complexity

C++ templates are really powerful. They can also be really, really obtuse, and I've seen a lot of those obtuse usages over the years. Additionally, things like full operator overloading are great if you want a smart pointer, but are often abused.

And don't get me started on #define.

The alternate view

So, if what I say above is true, the conclusion looks pretty clear - use C#. Not really much surprise considering who came up with the list.

But there are things that C++ has going for it, and it really depends on the kind of code you're writing which language is a better choice. In broad strokes (and in my opinion, of course), if you're doing user applications (either rich client or web), choosing C# is a no-brainer. When you start getting towards lower-level things like services or apps with lots of interop, the decision is less clear.

So, what do I think you get in C++? A few things spring to mind.

Absolute control over your memory

I think you actually need this level of control much less than you may think you need it, but there are times when you do need it.

Quick boot time

Spinning up the CLR takes extra time, and it's likely to alway take extra time (unless it's already spun up in some other manner). You don't pay this penalty in the C++ world.

Smaller memory footprint

Since you aren't paying for the CLR infrastructure, you don't pay for memory footprint.

Fewer install dependencies

You can just install and go, and your users don't have to install the proper version of the CLR.

So, that's pretty much what I said in the class. What did I miss?

What dyou think? In a lot of cases, C# could just as easily be Java.

No comments: