C++, C# and speed

By the time I had gained some confidence in my programming abilities, I had pretty much become a hardcore C++ fan. I’m a bit of a speed freak when it comes to programming. If something isn’t working as efficiently as it could be, I get a compulsion to look inside it, see what’s slowing it down and try to find a better way to do things (I know, it’s a curse). C++ lets you do this more easily than some languages because of its relative closeless to the hardware (code is compiled to native instructions, so there’s very little ‘unavoidable overhead’) as well as its high degree of expressibility (for example, I can think of about five ways to implement arrays off the top of my head, each one best suited to a particular situation).

Since starting level 2 of my course, I’ve been inclined by myself and lecturers to take a look at the bigger picture of the software development industry (a picture I’ve not had much of a chance to see, since I haven’t quite “broken in” yet). The thing I’ve gradually come to realise is that the end users don’t care whether software is blazingly fast, as long as it’s fast enough to do the job at hand. Things like ease of debugging and the ability to quickly add new features should always be paramount. If you always aim dogmatically for the most efficient solution (which C++ often tempts me to do) you might just be shooting yourself in the foot.

One of my modules in Computing is “Software Development: Tools and Principles” in which we all use Microsoft C#. We just recently started a huge project which must be programmed exclusively in this, so we have plenty of time to get comfortable with it. Now, I’d never even touched C# (or any languages of that nature, like Java) before I started the course, but luckily it’s similar enough to C++ in syntax to make the transition a pleasant one.

So in the few monthsI’ve been using C#, here are some of the things I’ve noticed that are different from C++ (and it’s mostly good stuff):

• No pointers – So that means no more messing around with the * character. You don’t seem to get as much control over memory, but going back to my point earlier: unless you’re concerned about super speed (in which case you probably wouldn’t be using a .NET language), it just means less hassle.
  You can still choose to pass objects by reference or value, and store objects as both classes (which exist on the heap) and structs (on the stack).
• More straightforward syntax – In C++ you need to use . to access members of objects on the stack, :: to access static members and things in namespaces, and -> to access instance fields.
  In C#, all of these are accessed using the dot character. And why not? The compiler should know what kind of object you’re referencing from the context its in, so the less rules you need to remember, the better.
• Garbage collection – Most programmers probably know this, but the .NET CLR uses a garbage collector by default. This means you don’t have to worry about freeing an object once it’s been created, because when you’re finished with it the memory will get recycled. If you’re not a big GC fan, you can override it by marking a block as ‘unsafe’, which will let you write unmanaged code, and allow you to use those lovely pointers.
• Exceptions for error handling – Because they’re made by different groups of people, common libraries used in C++ use quite a variety of methods to report when something’s gone wrong. Some will return boolean false, others will return an integer. Some won’t return anything but will put an error value somewhere for you to find yourself. In the Framework Class Library (the collection of ‘built-in’ classes within the .NET framework), everything uses exceptions to report problems. I haven’t seen many, but most 3rd party libraries seem to all use them extensively, too. So you’ll have much more consistency in your code, even if it uses code made by others.
• It’s JIT-compiled – This means your program can theoretically be ran on any system, because your code will stay in an abstract platform-independent form (known as Intermediate Language) until it’s ran, at which point it’s converted to the native code of the system it’s running on. This allows for processor-specific optimisations, which would be much more complicated to do in natively compiled apps. Some people aren’t fans of JIT-compiling because of the neccessary evils of extra memory and processor overhead, but processing power and memory are relatively cheap nowadays, especially for the kinds of companies who use JIT-compiled software in their industry.
  

So, in conclusion: if you want your software to be fast and in-touch with the hardware it’s on, use C/C++. If you want to be fast enough, and also instantly portable* onto other systems (see Mono), use .NET or Java.

* ok, this is arguable, but I still think it’s a step forward from natively compiled code.