1696193472_34d83c57f3[1]I know I just posted on the glories of smart pointers in C++.  I love C++ like a brother, and I have many C++ friends, but this article does a great job of illustrating, with wit and great examples, one of the most important truths about programming that I think I can pass on, and it’s not flattering to C++:

If you can manage it, try to swim with the current.

The link above is really a series of articles comparing the development of a simple application to read a Chinese dictionary in both unmanaged C++ and C#.  You should read it — it’s very interesting and educational — but the upshot is that although the C++ author eventually got his fully optimized performance to exceed that of the fully-optimized C# program, it took a large amount of very touchy, bug-prone work to do so, while the naïve version of the C# program already had great performance out of the box, and was easily optimizable to speed up further.

Why is this?  You can blame Microsoft’s substandard support for C++, and that’s probably partially right.  You can blame the glacial pace of improvement in C++ Standard Library design and performance, and that’s probably partially right as well.

But why are both of these situations the case?

The fundamental reason is that, for most non-systems programming tasks, the state-of-the art — the current — for development on Microsoft platforms is strongly flowing toward C# and .NET.  .NET is getting the benefits of new technologies and new advances in the craft of software development, and C++ really isn’t.  You can still paddle around in the C++ backwater, but very little in the way of support and improvements is going to be coming your way.  TR1 is very nice (and very overdue) but at this point it’s almost too little, too late.  Those of us who have to stay in the backwater are just going to have to get used to the faintly stagnant smell.

For most development, the current heading toward C# and .NET is almost certainly a good thing.  Personal computers are not the same as they were when C++ was first rising to dominance in the early 90s.  Multicore machines are the norm now, with multiple orders of magnitude more memory and disk storage than ever before.  Modern CPU pipeline optimizations are so complicated that trying to hand-optimize assembly code for a modern processor is almost laughable; a compiler will always do a better job than you can now, and that certainly wasn’t the case 15, even 10 years ago.

When you have memory to spare, a terabyte of hard disk space, most of the work you are doing is manipulating top-level UI constructs, your minimum-spec machine has an 8-core processor, and preventing obscure malicious exploits is a priority, does it make sense to use a language designed around minimalist efficiency, where threading is a foreign operation bolted on with great difficulty, memory is managed manually out of the box, security is an afterthought and you end up with a static executable optimized for the lowest common denominator of machine?  Or might it be better to use a language with built-in garbage collection, easily-used multithreaded constructs and just-in-time optimization based on the environment the app is running in?

C++ is a great language for many purposes, but the current has passed it by for user-level application programming.  Swim with the stream if you can!