Choosing Between C++ and C#

Thursday, May 01, 2008

During a recent Stackoverflow.com podcast, Jeff Atwood and Joel Spolsky discussed the question:

When is it correct to develop software (Windows software, in particular) in native C and/or C++?

Joel's response was basically "almost never". And while I wouldn't state it quite that strongly, the point he was trying to make is that, for most applications, there exists some language X which is a better (meaning: more appropriate) choice then C++ and especially, C.

Without getting embroiled in language wars, I can agree with this statement. C# is cleaner and more intuitive than legacy C/C++. The overwhelming consensus among Microsoft developers is that C# is the more productive language. And for all but the most intensive of applications, developer productivity trumps all other considerations.

However, as a long-time C++ and C# programmer myself, I have to say that even though C++ is often the wrong choice, there are still many, many situations in which it's the only choice:

• Cutting-edge 3D games.
  
• Graphical and audio workstation software.
  
• Large-scale productivity applications like Adobe Photoshop.
  
• Legacy codebases.
  
• Real-time systems of all sizes and descriptions.
  
• Anything involving extreme numerical computation.
  
• Large-scale data storage and retrieval.
  
• Device drivers.
  
• And so forth.
  

No other language offers the performance characteristics of C++ together with support for such a rich set of abstractions. Managed programs can get very fast, thanks to JIT compilation's ability to optimize for the native processor, but native C++ still outperforms managed C# across the board. And for any application where you need explicit control over large amounts of memory - for example, if you're building an RDBMS - C#'s garbage-collected approach is a deal-breaker.

Of course, most developers aren't sitting around coding 3D video games, or database engines. They're creating enterprise software, probably web-based. Or they're creating relatively lightweight desktop applications using WinForms. For these scenarios, C#, VB.NET, and or C++/CLI (also known as "managed C++") are the choices that will give an organization the most bang for its buck, in the long run.

In the non-Microsoft world, the story's a little different. If you want to program in C# for Linux, Unix, Solaris, et al., you'll probably end up using Mono. And the thing about Mono is it's open-source. Now, whatever your opinion on open-source development, one thing's certain: the future of Mono on *nix platforms is more uncertain than the future of .NET on Windows platforms. Don't get me wrong: Mono is supported by a thriving, vibrant developer community, and in all likelihood it'll be around...oh...approximating on forever.

But it doesn't have the weight of the Microsoft juggernaut behind it.

The thing about this particular question - I mean the question of C# vs. C++ - is that there just aren't that many borderline cases. Usually, some characteristic of the project will jump out at you, and it'll be obvious which language is appropriate. If you're doing hardcore systems or application development, C++ is probably for you. For everything else, C# is probably way to go. And in practice you'll find that it's something like 80% C#, and 20% C++, give or take 10%.

Now, as hardware continues to improve, expect this percentage to change. If you don't need the performance, there's very little reason to use C++ these days at all. Managed C# applications running on today's hardware are visibly faster than native C++ applications running on ten-year old hardware, and we can expect that trend to continue.

But as of right now: C++ is the only choice for hardcore application development. It's just a question of deciding what hardcore really means, in the face of ever-more-powerful hardware.

Tags: C++, C#

8 comment(s)

Your comment:

Name:
Website:
Email:

Subscribe by RSS Subscribe by Email