The only game in town

Introduction

There has been a little bit of resurgence for functional languages, I myself have on occasion spoken for functional languages, as have Christer Ericson and several others. Functional languages just makes sense in a way that you really can't appreciate until you've dabbled a little bit with them. The elegance of it all takes my breath away. Algorithms fall naturally out, the syntax is usually clear, precise and to the point without any ADA or COBOL like verbosity. Traditionally the tools support for functional languages have, well sucked vacuum, which prevented anyone in their sane mind to actually use them for anything in real productions [1].

Now, one might point out that this and that functional language is better in some sense, but when it comes down to it, they simply don't have the right tools, or even the talent pool to hire from, to make them viable languages for games. So we continue on with C++. Which brings me to my next point, we use it since it's the only game in town. Really, it sucks, it's awful and the atrocities you can commit in this languages boggles my mind. But the fact is that all other alternatives suck even more and are less suitable for console games development. Sombody called C++ "the most tragic local maxima in the games industry", and it's sad but true. So while I continue to bitch and moan about the deficiencies of C++ I still use it. I still think it's the best thing available, but from a poor selection indeed. It's 2008 god damn it. Where is my personal jet pack? Where is all that computer nonsense that I saw on TV in the 80s? It's more complicated than ever to actually use a computer, and to program it you have to actively go and find the manuals. Complicated manuals. It's not like the good old days when I had my Commodore 64, which had an instant programming language at the tip of the power switch, a very simple processor (good old 6502) and an actual paper manual which showed me how to actually use and program the computer. Today you are lucky if you get a shiny pamphlet that shows how to connect all the cables and that is it! I mean, today's youth is completely taken aback that there is a built in help in windows (arguably that one is really bad and incomplete). Buying your kid a computer today and expecting them to learn how to program is not feasible. On the other hand one can today with a little bit of google fu dig up the most amazing things, so I guess it's a wash in the end. But I miss paper manuals.

The only game

But I digress, C++ was the game. The only game in town. The problem I have with C++ is that it's far too easy to mess up. You basically need to be fluent in the standard to be able to program any of the advanced features, like casting a pointer into another! No seriously, that is one of the most common errors I've seen. Every time you cast a value to another you need to ask yourself if it's legal. I promise that 99% of the cases it's not due to aliasing issues (again see paragraph 3.10.15 in the standard or read a more verbose explaination of strict aliasing by Mike Acton). And for the remaining 1%, consult the assembly before opening the champagne. As we are trying to make the compilers better at optimizing for speed, and as we move away from out of order instruction CPUs and in favor of in order (Xbox 360, PS3 and Larrabee) more of the burden for good efficient code it placed on the compiler. And they only way the compiler can make the code faster is to rely on promises of the language and then do safe transformation based on this. But if the programmer has broken the standard, i.e. not know that the heck the language is, then the compiler will most probably (if it's not Visual Studio, because it does very little in terms of these optimizations) produce garbage. Absolute garbage. And it will tell you nothing. Because you lied to it and it's sulking.

Now there are a couple of items in the language that you should try to stay away from since they usually cause really big headaches and require intimate understanding of the standard. Especially if they are intermixed, since most of the things are orthogonal from each other.

• Template meta programming. No. Don't even think about it. There are always better ways to do it. Less glamorous perhaps, but better. The problem with template meta programming is that it's very cool in a way that you are doing something that's fairly complicated, but not the way the language was designed for. The fact that it is considered clever is another red flag, almost invariably clever code will get you into trouble. Remember that you need to be twice as clever to debug the code as you were when you wrote it. And I can not even begin to read the error messages out of the compiler during template meta programming.
• Multiple inheritance. Always a bad idea if you're not forced by a third party vendor. And if that is the case, either convince them to change their APIs or switch vendor. This is absolute madness, since it requires nontrivial knowledge of the object model in C++. If you mix casts and virtual functions into the mix, then you are either on the standard committee or a clueless fool. Either way, you will wind up with code that will be extremely hard to debug and understand, and we all know that sooner or later you will have to debug this...
• More than one level of inheritance, or inheritance from non pure abstract base classes. This is just ill advised.
• Casting before reading 3.10.15 in the standard. And even after that you should cast pointers with extreme care. And never ever cast a float pointer into an int pointer. Never. Every time you do that, a cute little kitten dies. And on top of that, with most optimizing compilers you will run the risk of getting the wrong result due to register optimizations. Consider the following code:

  float abs(float a)
  {
  	*((int*)&a) &= ~0x80000000;
  	return a;
  }
  

  Of course the problem with this is that you probably will never get the sign bit cleared since the compiler will generate the following code:

  blr
  

  WTF? Since the compiler will pass the floating point value into the function in a float register, and then it sees that no float operations are done, and then return the result in the same float register, a good optimizing compiler will see that the integer operations can not possibly affect the float value (this is correct), realize that no reshuffling of registers is needed and insert the single return statement. Now compilers that doesn't do such a good analysis will probably (and I use the word probably) generate code that will clear the sign bit. In this case that is probably what the programmer intended (but incorrectly coded), but consider all the other cases where you actually want the compiler to be smart and generate the minimal and optimal set of assembler instructions to do what you told it to do. Actually, it's probably a whole blog post just to discuss the finer pointers of casting pointers.

I first learned C++ about 13 years ago and I still find new things about it that I simply didn't know. The standard is absolutely huge and it is very hard to keep up and learn all of it. My current strategy is to limit the parts of the language that I use to those that I'm comfortable with, as well as the runtime and the compiler (since traditionally the compilers that have been standards compliant have been very few. Microsoft Visual Studio has never been one of them, still isn't. And the vast majority of Visual Studio developers run in the most non-standard compliant mode, i.e. they don't turn on /Za). Now that part of the language is probably surprisingly small, although I perhaps feel that others overextend into areas where they certainly shouldn't be.

In closing

So is there no help? Well, there are a couple of books you should read up on. One of them is my all time favorite book, Expert C Programming: Deep C Secrets. It's really an excellent book that clears up such important concepts like why a pointer and an array is not the same, what interposing is (and why it's a pain in the ass during linking) sprinkled with anecdotes from the computer world that makes it a very good read in it's own. Don't let the fact that it's a C book stop you, the concepts in this book are the fundamentals of C++ as well. The second one is Inside the C++ object model, which you should just pick up if you are seriously contemplating doing anything that requires low level understanding of how the language works. Like figuring out where from the this pointer a certain variable is. In a safe manner. Third, if you are serious about programming in C++, you should pick up a copy of the Annotated C++ Reference Manual. It covers the old standard, but see it as a book that teaches you how to read a reference manual and then pick up a copy of the real standard (electronic or the paper version).

However, even armed with the knowledge contained in these books, proceed with extreme caution and choose your battles. There is a reason why there is a myriad of books out there for C++ that has traps, pitfalls and tricks in their titles.

Footnotes

[1] Although it you're really good, like Naughty Dog, you say screw it, I'll just write my own tools, including compiler. They did just this for GOAL, a lisp derivative to drive their PS2 games like Jak and Daxter. So it can be done, but a lot of effort is required. Apparently, Mario 64 was also written with some form of LISP.