I just had a case where I wanted to make sure that a C++ template parameter was of a certain type. The template should be used for pointers to instances of class “Base” and its derivates so that I could call a method of Base on the object provided to the template class. First, I thought there would be no way to achieve this, but then I tried a static_cast which turned out to be the solution: using the static_cast ensures that the type casted to is used at compile-time. Isn’t that beautiful? If you don’t need to access the object but constrain the template to a certain type, you could use the d’tor to implement some dummy code. Using this template with a type which is neither “Base” nor inherited from “Base” leads to a compiler error like “can’t convert ‘bad type’ to ‘Base’.

I just read something in AI Game Programming Wisdom 3 which sounded sooo familiar to me. Sergio Garces of Pyro Studios writes about game architecture regarding the game objects, “… we often see examples of inheritance abuse, making the fundamental mistake of confusing behaviour (what objects do) with identity (what objects are)” This is exactly one of the many mistakes I did in DVW, where the inheritance hierarchy is like Entity<-Unit<-Vehicle<-Constructor<-KPBConstructor or Entity<-Unit<-Building<-UnitFactory<-BunkerBarracks. It works, but this really is not the way I would do again. Next time, I would use a part-based approach like sheijk|6S is doing in Velox3D, i.e. the game designer (not necessarily the programmer!) creates units out of several abilities, just like plugging and playing: plug in a motor, and the entity could move; plug in a weapon, and the entity could attack or fight back; plug in a brain (i.e. some AI) and it knows how to use its parts. But we’re making good progress anyway.

Today I was discussing about how one could implement a stacktrace in C++, where one has not the luxury of Thread.dumpStack() or Throwable.printStackTrace(…) of Java. The general C++ approach one finds often is to create a dummy object on the stack at the beginning of each method which receives the current file and function as constructor parameters (using the __FILE__, __FUNCTION__ and __LINE__ macros) and stores them, i.e. increases a list pointer and saves the const char* at the resulting position. As soon as the object gets destructed at the end of the function, the list header pointer is decreased again. So, my first implementation looked like this: The first test with an exception I threw somewhere deep in the call hierarchy of my program revealed what one has to remember about exceptions: objects that exist on the stack at the time the exception is thrown are ordinary destructed. So, the d’tor of my CallStack object was called, too, and current was not pointing to where I had expected. So I had to mark the …