In order to keep things simpler and only concentrate on the crucial elements, we don’t deal with per-class new/delete, and we don’t want to mess with exceptions either, as they are rarely used in run-time game code.

new operator / operator new

The first thing to understand is that there is a difference between the new operator and operator new. Let’s look at a very simple statement involving the keyword new:

T* object = new T;

This is the simplest form of the new operator, probably used in many, many places in your code. What does it really do behind the scenes?

1. First, a call to operator new (note the difference!) is made to request storage for a single T.
2. Second, the constructor for T is called which constructs the new instance of T at the memory address returned by the previous call to operator new.

If T is of fundamental type (e.g. int, float, etc.), or does not have a constructor, no constructor will be called. The above statement will call the simplest form of operator new:

void* operator new(size_t bytes);

Notice the size_t argument – the compiler will automatically insert code for calling operator new with the correct size for a given type, which is sizeof(T) in our case. Because operators behave like ordinary functions, they can be called manually, and can have different overloads as well. Those overloads can also be invoked by using different versions of the new operator, with the compiler generating code for calling the corresponding version of operator new. In fact, there’s another standard version of the new operator, with so called placement-syntax:

void* memoryAddress = (void*)0x100;
T* object = new (memoryAddress) T; // placement-syntax, known as placement new

This can be used to construct instances of classes at a certain place in memory, which in essence is the only way of calling constructors “directly”, because no memory allocation is involved here – the above calls a different overload of operator new, which is the following:

void* operator new(size_t bytes, void* ptr);

Even though this form of operator new takes size_t as the first argument, it does not allocate any memory, and just returns the pointer given in the second argument. That’s why our example simply invokes the constructor T::T() at address 0×100.

The placement-syntax of the new operator is very powerful, because it allows us to invoke different overloads of operator new with an unlimited number of custom arguments. The only rule is that the first argument to every operator new must always be of type size_t, which will automatically be passed to it by the compiler.

Again, let’s look at an example illustrating the above:

void* operator new(size_t bytes, const char* file, int line)
{
  // allocate bytes
}
 
// calls operator new(sizeof(T), __FILE__, __LINE__) to allocate memory
T* object = new (__FILE__, __LINE__) T;

Leaving differences between global operator new and class operator new out of the equation, every use of the placement form of the new operator boils down to the following internally:

// calls operator new(sizeof(T), a, b, c, d) to allocate memory
T* object = new (a, b, c, d) T;

Which is semantically equivalent to:

T* object = new (operator new(sizeof(T), a, b, c, d)) T;

The magic of calling operator new is simply done by the compiler. Furthermore, remember that every overload of operator new can be called directly like ordinary functions, and we can do whatever we want with the different overloads. For example, we can even use templates if we want to:

template <class ALLOCATOR>
void* operator new(size_t bytes, ALLOCATOR& allocator, const char* file, int line)
{
  return allocator.Allocate(bytes);
}

This comes in handy later when we’re about to use different allocators, and want to provide additional arguments like e.g. alignment boundaries. The placement-syntax allows us to conveniently allocate memory with e.g. the following single-line statement:

T* object = new (allocator, alignment, __FILE__, __LINE__) T;

delete operator / operator delete

This is probably no big surprise, but again, it is crucial to understand that there is a difference between the delete operator and operator delete. Calling the delete operator on a previously new‘ed instance will first call the destructor, and then operator delete. Apart from the reverse order of operations, there’s another difference between new and delete: Regardless of which form of new we used to create the instance, the same version of operator delete will always be called (which is rather unfortunate when trying to implement advanced memory system techniques in later parts of the series):

// calls operator new(sizeof(T), a, b, c, d)
// calls T::T()
T* object = new (a, b, c, d) T;
 
// calls T::~T()
// calls operator delete(void*)
delete object;

The only time the corresponding operator delete is called by the compiler is when an exception is thrown inside operator new, so the memory can correctly be freed before the exception is propagated to the calling site. This is also the reason why every overload of operator new must always have a corresponding version of operator delete, even if it’s never called. But let’s not digress, we don’t want to deal with exceptions further.

Like operator new, operator delete can also be called directly (like an ordinary function):

template <class ALLOCATOR>
void operator delete(void* ptr, ALLOCATOR& allocator, const char* file, int line)
{
  allocator.Free(ptr);
}
 
// call operator delete directly
operator delete(object, allocator, __FILE__, __LINE__);

However, do not forget that the destructor is called by the delete operator, not operator delete. Hence, in the above example, the destructor needs to be called manually:

// call the destructor
object->~T();
 
// call operator delete directly
operator delete(object, allocator, __FILE__, __LINE__);

If instances are created wih the simple placement-form of new, the destructor must always be called manually. Using delete on such an instance would invoke undefined behaviour (because the memory was never allocated with a call to new). Keep this in mind whenever you use placement new!

Having thoroughly discussed new/delete, let us take a look at their array siblings, new[] and delete[].

new[] / delete[]

Even though you have probably used it a thousand times already, you may not realize that in something so fundamental such as new[] and delete[], there’s already compiler magic involved. The reason for this is that the C++ standard just mandates what new[] and delete[] should do, but not how. Let us take a closer look, again starting with a simple example:

int* i = new int [3];

Similar to the new operator, the above allocates storage for three ints by calling operator new[] (requesting memory), and since int is an integral type, there are no constructors to call. Similar to operator new, we can overload operator new[] and use placement-syntax as well:

// our own version of operator new[]
void* operator new[](size_t bytes, const char* file, int line);
 
// calls the above operator new[]
int* i = new (__FILE__, __LINE__) int [3];

delete[] and operator delete[] behave similar to delete and operator delete – we can call operator delete[] directly if we wish, but must make sure to call the destructors manually (in reverse order). Nothing too fancy, but what happens with non-POD types?

struct Test
{
  Test(void)
  {
    // do something
  }
 
  ~Test(void)
  {
    // do something
  }
 
  int a;
};
 
Test* objects = new (__FILE__, __LINE__) Test [3];

Even though sizeof(Test) == 4 (MSVC 2010, Windows 32-bit platform), our version of operator new[] will get called with an argument of 16 bytes, instead of 12 bytes. Why? Think about how the array needs to be deleted:

delete[] objects;

The compiler must somehow know how many instances of type Test are to be deleted – otherwise it can’t call the instances’ destructors. So what almost every compiler does upon a call to new[] is the following:

• For N instances of type T, request an allocation for sizeof(T)*N + X ‘extra’ bytes from operator new[].
• Store N somewhere in the first X bytes.
• Construct N instances using placement new, starting at ptr + X.
  
• Return ptr + X to the user.

Most of the time – if you don’t specify a particular alignment for a class using __declspec(align) (MSVC) or __attribute__((aligned)) (GCC) – the amount of extra bytes requested will be 4, but that depends on both your class’ alignment restrictions and the compiler. For example, if you specify Test to be 16-byte aligned using __declspec(align(16)), MSVC 2010 will request a total of 64 bytes in the example above.

As an example, let us use the definition of class Test from above: If your overload of operator new[] returns the memory address 0×100,  Test* objects will point to 0×104, because of the extra 4 bytes requested by the implementation! The memory layout of the 16 bytes would then be:

0x100: 03 00 00 00 -> number of instances stored by the compiler-generated code
0x104: ?? ?? ?? ?? -> objects[0], Test* objects
0x108: ?? ?? ?? ?? -> objects[1]
0x10c: ?? ?? ?? ?? -> objects[2]

When delete[] is used later on, the compiler inserts code which reads the number of instances N by going back 4 bytes from the given pointer, and calls the destructors in reverse order – if the type to be deleted is non-POD. Otherwise, there’s no 4 byte overhead added because no destructors need to be called (like in the new int[3] example above). If you ever wondered what the vector deleting destructor() in MSVC is for, there is your answer. Unfortunately, this compiler-defined behaviour causes problems when using our own overloads for operator new[] and operator delete[].

As an example for using custom overloads, we might want to pass alignment restrictions to operator new[], and return correctly aligned memory (e.g. on a 16-byte boundary). However, the compiler-implicit offset that is added to whatever we return will definitely screw with our alignment. Additionally, when we want to call operator delete[] directly, we somehow need to figure out how many destructors to call (if any).

Which we can’t.

The reason is that we can never be sure whether the compiler inserted some extra bytes (4, 8, or possibly more) in the allocation or not. This is totally compiler-dependent. It might work, but it could also horribly break with some user-defined types. And other compilers could do it differently altogether.

This is also the reason why using delete on instances allocated with new[] invokes undefined behaviour, and vice versa. The compiler-generated code simply tries to access memory which doesn’t belong to it (using delete[] for allocations via new), or not all instances of an array are correctly destructed (using delete for allocations via new[]). This can have zero consequences (if the types don’t have a destructor), or crash your code (if the types have a destructor).

However, with the knowledge of what happens behind the scenes with calls to new, new[], delete and delete[], we can build our own allocation functions which correctly handle simple and array allocations for all types, can use our custom allocators, provide additional information like file name and line number, and more. The next post in this series will show how.

In the meantime, in case you want to read more about global operator new and class operator new (which we didn’t discuss here), here are recommended links:

new (C++)
delete (C++)

Thanks to Michael Tedder, Paul Laska and Bruce Dawson for the feedback!

The problem

Let us assume that we want to add logging facilities to our game, and for that purpose we build a simple base class called Logger, which can be extended (or completely replaced) simply by deriving from it and overriding a virtual function. Note that we are not concerned about how log messages are dispatched to the different logger implementations, but rather how new logger-classes with completely different functionality are implemented.

A simple base class for loggers might look like the following:

class Logger
{
public:
  virtual ~Logger(void) {}
 
  virtual void Log(size_t channel, size_t type, size_t verbosity, const SourceInfo& SourceInfo, const char* format, va_list args) = 0;
};

As you can see, it’s nothing more than a very simple base class with one virtual function. The arguments are the log-channel (e.g. “TextureManager”, “SoundEngine”, “Memory”, etc), the type of log (e.g. INFO, WARNING, ERROR, FATAL), the verbosity level, a wrapper around source-code information called SourceInfo (file name, function name, line number, etc.), and last but not least the message itself in terms of a format string and a variable number of arguments. Nothing spectacular so far.

One possible logger implementation could be the following:

class IdeLogger : public Logger
{
public:
  virtual void Log(/*arguments omitted for brevity*/)
  {
    // format message
    // do additional filtering based on channel, verbosity, etc.
    // output to IDE/debugger
  }
};

The IdeLogger outputs all log messages to e.g. the MSVC output window by using OutputDebugString(). In order to do that, it formats the message in a certain kind of way, applies additional filtering based on the channel, verbosity, etc., and finally outputs the message. We might want another logger which logs to the console, and one which writes into a file, so we could simply add two additional classes called ConsoleLogger and FileLogger, which both derive from the Logger base class.

Sooner or later, this is where we run into problems, depending on what we want:

• A logger which writes to the console, but only filters based on the channel, not the verbosity level.
• A logger which writes into a file, but doesn’t filter any messages because they are a useful tool for post-mortem debugging.
• Slightly different formatting in one of the existing loggers, e.g. I like being able to click on log messages in Visual Studio’s output window because they are formatted like this:
  “C:/MyFilename.cpp(20): [TextureManager] (WARNING) Whatever.”
• A logger sending messages over a TCP socket, without having to copy existing code for formatting/filtering.
• Many more such features…

A deceivingly simple solution

One solution which is sometimes applied to such problems is to put certain parts of an implementation into several base classes, and build a deep hierarchy of classes by using multiple inheritance. In essence, you end up with classes like ConsoleLoggerWithVerbosityFilter, FileLoggerWithoutFilter and TcpLoggerWithExtendedFormatting which multiply inherit from concrete implementations of base classes like ILogFilter, ILogDestination and ILogFormat. Personally, I tend to favor flat hierarchies without any coupling over deep hierarchies where leaf classes are sometimes affected by changes to some base class.

Furthermore, judging from experience you often need to add a bunch of virtual functions to such hierarchies only to make some leaf class work, or end up copy-pasting existing code because a seemingly innocent change might break some of the existing implementations, which is why I try to stay away from such solutions – they might work for certain problems, but I’ve often seen them break during the development of a product.

Anatomy of the problem at hand

Let us take another look at the problem, this time from a different angle, leaving out implementation details like base classes, inheritance, and so on.

What we essentially want is a mechanism which makes it easy to define new loggers based on existing functionality without copying any code, and without having to write a new logger implementation each and every time. What we want is a mechanism where parts of the implementation could essentially be assembled by writing only a few lines of code.

By splitting the logger’s responsibilities into smaller pieces, we can hopefully find some orthogonal functionality along the way. A logger essentially:

• filters the incoming message based on certain criteria, then
• formats the message in a certain way, and finally
• writes the formatted message to a certain output.

If you think about it, these aspects are completely orthogonal to each other, which means that you can exchange the algorithm for filtering messages with any other without having to touch either the formatting or writing stage, and vice versa.

What we now would like to have is some mechanism for exchanging those aspects with very little amount of code. Such a mechanism can be achieved by making use of templates, like in the following example:

template <class FilterPolicy, class FormatPolicy, class WritePolicy>
class LoggerImpl : public Logger
{
public:
  virtual void Log(/*arguments omitted for brevity*/)
  {
    // pseudo code-ish...
    if (m_filter.Filter(certain critera))
    {
      m_formatter.Format(some buffer, criteria);
      m_writer.Write(buffer);
    }
  }
 
private:
  FilterPolicy m_filter;
  FormatPolicy m_formatter;
  WritePolicy m_writer;
};

The above is a very generic logger which passes on the tasks of filtering, formatting and writing messages to certain policies, which are handed down to the implementation via template parameters. Each policy does only a very small amount of work, but by combining them you can come up with several different logger implementations with only a single line of code, by means of a simple typedef, as shown later.

Example policies

Before we can discuss the pros/cons of this approach, let us quickly identify what some of the policies might look like in order to gain a better understanding of how such a system works:

Filter policies

struct NoFilterPolicy
{
  bool Filter(const Criteria& criteria)
  {
    // no filter at all
    return true;
  }
};
 
struct VerbosityFilterPolicy
{
  bool Filter(const Criteria& criteria)
  {
    // filter based on verbosity
  }
};
 
struct ChannelFilterPolicy
{
  bool Filter(const Criteria& criteria)
  {
    // filter based on channel
  }
};

As you can see, each policy takes care of filtering messages based on certain criteria, nothing more.

Format policies

struct SimpleFormatPolicy
{
  void Format(const Buffer& buffer, const Criteria& criteria)
  {
    // simple format, e.g. "[TextureManager] the log message";
  }
};
 
struct ExtendedFormatPolicy
{
  void Format(const Buffer& buffer, const Criteria& criteria)
  {
    // extended format, e.g. "filename.cpp(10): [TextureManager] (INFO) the log message";
  }
};

Writer policies

struct IdeWriterPolicy
{
  void Write(const Buffer& buffer)
  {
    // output to the IDE
  }
};
 
struct ConsoleWriterPolicy
{
  void Write(const Buffer& buffer)
  {
    // output to the console
  }
};
 
struct FileWriterPolicy
{
  void Write(const Buffer& buffer)
  {
    // write into a file
  }
};

Discussion

By dissecting the problem into different aspects, we can now implement very small functions/structs called policies, which can be assembled together in any way we wish by using just a single line of code. Some examples:

typedef LoggerImpl<NoFilterPolicy, ExtendedFormatPolicy, IdeWriterPolicy> IdeLogger;
typedef LoggerImpl<VerbosityFilterPolicy, SimpleFormatPolicy, ConsoleWriterPolicy> ConsoleLogger;
typedef LoggerImpl<NoFilterPolicy, SimpleFormatPolicy, FileWriterPolicy> FileLogger;

Advantages

• With only 3 filter policies, 2 format policies, and 3 writer policies we are able to come up with 3*2*3 = 18 different implementations, just by using a simple typedef.
• Each part of an implementation can be replaced separately, so if you e.g. add a TcpWriterPolicy you can combine it with any other filter or format policy, without having to resort to copy-pasting.
• Pieces of policies can be assembled in any way we want.
• New policies can be build using existing policies simply by combining them.
• If any combination of policies does not exactly do what you want, you can still implement your own logger by deriving from the Logger base class, without being forced into a certain inheritance structure, except the single virtual function in the base class.
• Simple, flat hierarchies, no multiple inheritance used.
• One virtual function call instead of several ones (multiple inheritance of several interface classes).
• Unit testing becomes a lot more easier because each policy has exactly one responsibility.

An example of how to build new policies out of existing ones:

template <class Policy1, class Policy2>
struct CompositeFilterPolicy
{
  bool Filter(const Criteria& criteria)
  {
    return (m_policy1.Filter(criteria) && m_policy2.Filter(criteria));
  }
 
private:
  Policy1 m_policy1;
  Policy2 m_policy2;
};
 
typedef LoggerImpl<CompositeFilterPolicy<VerbosityFilterPolicy, ChannelFilterPolicy>, ExtendedFormatPolicy, IdeWriterPolicy> FilteredIdeLogger;

Drawbacks

• Template parameters are part of the class name, leading to longer class names, in turn making the code harder to debug if you’re not used to it.
• Increased compile times if you’re not careful. I would recommend using explicit template instantiation for required logger implementations.

Conclusion

Policy-based design is a powerful tool which can be used in several situations, not just the one shown here. It can lead to extendable and modular classes if applied correctly, but it isn’t a silver bullet which can forever solve our architectural problems, hence it shouldn’t be applied blindly.

Dealing with function template code can sometimes result in errors being emitted by the compiler because template argument deduction is ambiguous. Most of the time, casts are used to battle these errors, but often there’s a more elegant solution to the problem.

The following code shows a very simple function template for returning the maximum of any two values, build as a template in order for it to work on any type:

template <typename T>
T Max(T lhs, T rhs)
{
  return (lhs >= rhs) ? lhs : rhs;
}

The function is built as a template in order to be able to specialize it for e.g. float, using fast, branch-less floating-point selects (fsel) on consoles. The same can be done for other functions such as Min, Clamp, etc. – but let’s not digress.

Such a template function can either be called with or without an explicit template argument:

// explicit template argument
int max = Max<int>(100, 200);
 
// template argument omitted
int max = Max(100, 200);

If the template argument is omitted when calling a template function, figuring out the correct type T is up to the compiler, which is done using a process known as template argument deduction.

But when dealing with template argument deduction, the values involved do not undergo standard conversions such as type promotions:

int i = 100;
int max = Max(i, 200u);

The above code will result in the following error:

error C2782: 'T Max(T,T)' : template parameter 'T' is ambiguous
could be 'unsigned int'
or       'int'

Of course, in this example we could have just written 200 instead of 200u and that would have fixed the problem, but it gets more interesting when dealing with enums and class conversion operators:

enum Test
{
  VALUE_1 = 1,
  VALUE_10 = 10
};
 
struct TestClass
{
  operator int(void)
  {
    return 10;
  }
};
 
// ambiguous, eventhough enums can be implicitly converted to ints
int max = Max(100, VALUE_10);
 
// needs an explicit cast
int max = Max(100, static_cast<int>(VALUE_10));
 
// ambiguous, eventhough TestClass defines a conversion operator
TestClass tc;
int max = Max(100, tc);
 
// again, needs an explicit cast
TestClass tc;
int max = Max(100, static_cast<int>(tc));

As can be seen, even though 10 and VALUE_10 can easily be treated as ints, the template argument deduction process is ambiguous, because the types the compiler sees are int and Test, hence it doesn’t know which one to choose. The same happens with instances of type TestClass, which defines a conversion operator to int – in both cases we need to add an explicit cast as a workaround.

It would be nice if we could somehow tell the C++ compiler to carry out conversion and type promotion first, before deducing template arguments. Luckily, it turns out that there is a way to do that, by way of using the unary+ operator:

// works with type promotion
int max = Max(100, +VALUE_10);
 
// works with conversion operators
TestClass tc;
int max = Max(100, +tc);

Notice the plus in front of VALUE_10 and tc. Using this operator, the types used in template argument deduction will first undergo implicit conversions, solving such problems without having to either assign to a temporary variable, or using an explicit cast.

 This is an older post from my blog, but I figured it might be useful to others as well.

Texture* tex = textureLibrary->FindTexture("my_texture");
ShaderParameter param = shader->FindParameter("matrixWVP");

For today, we are not so much concerned about how the key-value pairs are stored, and how the look-up is done internally (read this excellent post instead), but rather how to get rid of any hashing done at run-time. You might be surprised at how good C++ compilers have become when it comes to evaluating expressions known at compile-time, so let us put that to good use.

Assuming all our textures are stored in a table using some kind of (Hash, Texture) key-value pair (be it in a std::map, a simple array, or something more advanced), the code for finding a texture would vaguely look as follows:

Texture* TextureLibrary::FindTexture(const char* name)
{
  const unsigned int hash = CalculateHash(name);
  // lookup the texture in some container using 'hash'
}

So even for constant strings, CalculateHash() will still be called, and the hash has to be generated each and every time this function is called with a constant string. This is something we would like to get rid of.

The first step is to ensure that each and every class dealing with hashes makes use of the same functionality, while still retaining the same syntax for users of those classes. So instead of taking a const char* as argument, we could define a simple class holding nothing more than a hash internally, which will be passed to the function by value instead:

class StringHash
{
private:
  unsigned int m_hash;
};
 
Texture* TextureLibrary::FindTexture(StringHash hash)
{
  // no more hash calculations in here
  // lookup the texture in some container using 'hash'
}

This way, our hashed string class can tackle the problem of distinguishing between constant and non-constant strings, and we can be sure that no hash calculations take place inside the function. But still, how do we make sure that constant strings are not re-hashed every time?

A simple hash function

Let’s assume that hashing strings is done using a simple FNV-1a hash with the following implementation:

unsigned int CalculateFNV(const char* str)
{
  const size_t length = strlen(str) + 1;
  unsigned int hash = 2166136261u;
  for (size_t i=0; i<length; ++i)
  {
    hash ^= *str++;
    hash *= 16777619u;
  }
 
  return hash;
}

Looking at the above FNV-1a hash implementation, let’s try to figure out the resulting hash values for known strings (don’t forget about the null terminator):

• “” = (2166136261u^ 0) * 16777619u
• “a” = (((2166136261u^ ‘a’) * 16777619u)^ 0) * 16777619u
• “ab” = (((((2166136261u^ ‘a’) * 16777619u)^ ‘b’) * 16777619u)^ 0) * 16777619u)

The algorithm’s offset and prime are compile-time constants (I used 2166136261u and 16777619u in the example above), so these expressions really are constant.

Helping the compiler

All we need to do is give the compiler some help, which can be achieved by providing concrete implementations for strings of different lengths. Let’s put those into our StringHash class:

class StringHash
{
public:
  ME_INLINE StringHash(const char (&str)[1])
    : m_hash((2166136261u^ str[0]) * 16777619u)
  {
  }
 
  ME_INLINE StringHash(const char (&str)[2])
    : m_hash((((2166136261u^ str[0]) * 16777619u)^ str[1]) * 16777619u)
  {
  }
 
  // other implementations omitted
};

In case you’re not familiar with the syntax (and admittedly it’s one of the more awkward ones in C++), the constructors take references to const-char-arrays of sizes 1, 2, and so on. Providing different implementations for strings of different length tremendously helps the compiler/optimizer to fold the constant expressions into the final hash. In addition, we force each constructor to be inlined using ME_INLINE, which is a platform-independent variant of e.g. __forceinline (Visual Studio 2010), passing an additional hint to the optimizer.

Spotting the pattern

Many of you may have already spotted the (offset^constant)*prime pattern in the above examples, and indeed we can easily implement our constructors by utilizing the preprocessor:

#define PREFIX(n, data)		((
#define POSTFIX(n, data)	^ str[n]) * 16777619u)
 
#define ME_STRING_HASH_CONSTRUCTOR(n)									\
ME_INLINE StringHash::StringHash(const char (&str)[n])							\
  : m_hash(ME_PP_REPEAT(n, PREFIX, ~) 2166136261u ME_PP_REPEAT(n, POSTFIX, ~))				\
{													\
}
 
class StringHash
{
public:
  ME_STRING_HASH_CONSTRUCTOR(1)
  ME_STRING_HASH_CONSTRUCTOR(2)
  ME_STRING_HASH_CONSTRUCTOR(3)
  ME_STRING_HASH_CONSTRUCTOR(4)
  ME_STRING_HASH_CONSTRUCTOR(5)
  ME_STRING_HASH_CONSTRUCTOR(6)
  ME_STRING_HASH_CONSTRUCTOR(7)
  ME_STRING_HASH_CONSTRUCTOR(8)
 
  // other constructors omitted
};

Did it work?

With this in place, let’s take a look at the assembly code generated by the compiler to see whether our trick really worked. We will use the following simple example for that:

printf("Hash test: %d", StringHash("").GetHash());
printf("Hash test: %d", StringHash("test").GetHash());
printf("Hash test: %d", StringHash("aLongerTest").GetHash());
printf("Hash test: %d", StringHash("aVeryLongTestWhichStillWorks").GetHash());

The resulting assembly code (Visual Studio 2010) looks like this:

printf("Hash test: %d", StringHash("").GetHash());
  01311436  push        50C5D1Fh
  0131143B  push        offset string "Hash test: %d" (13341ECh)
  01311440  call        printf (1328DD0h)
printf("Hash test: %d", StringHash("test").GetHash());
  01311445  push        0AA234B7Fh
  0131144A  push        offset string "Hash test: %d" (13341ECh)
  0131144F  call        printf (1328DD0h)
printf("Hash test: %d", StringHash("aLongerTest").GetHash());
  01311454  push        444D1A47h
  01311459  push        offset string "Hash test: %d" (13341ECh)
  0131145E  call        printf (1328DD0h)
printf("Hash test: %d", StringHash("aVeryLongTestWhichStillWorks").GetHash());
  01311463  push        6D9D8B39h
  01311468  push        offset string "Hash test: %d" (13341ECh)
  0131146D  call        printf (1328DD0h)

As can be seen from the generated instructions (push 50C5D1Fh, push 0AA234B7Fh, push 6D9D8B39h and push 6D9D8B39h), the compiler/optimizer was indeed able to fold every string into its corresponding hash at compile-time, completely eliminating all traces to any StringHash constructor.

Finishing touches

All is well for constant strings, but what about non-constant ones? Of course we might want to use some kind of non-hardcoded string (e.g. a std::string, or strings coming from a file) every now and then, and need to provide a constructor for those as well:

class StringHash
{
public:
  StringHash(const char* str)
    : m_hash(CalculateFNV(str))
  {
  }
 
  ME_STRING_HASH_CONSTRUCTOR(1)
  ME_STRING_HASH_CONSTRUCTOR(2)
  ME_STRING_HASH_CONSTRUCTOR(3)
  ME_STRING_HASH_CONSTRUCTOR(4)
 
  // other constructors omitted
};

Now we’re in trouble. C++ overload resolution dictates that const char (&str)[N] is as good a match for any of the constructors as const char*, because every array decays into a pointer automatically. This means that our class no longer works, because every constructor call is ambiguous:

// error: constructor overload resolution was ambiguous
printf("Hash test: %d", StringHash("test").GetHash());

What we need to do is make the overload resolution process jump through another hoop for const char* arguments, so that constant string are considered first, and non-constant ones second. This can easily be achieved by using the following trick:

class StringHash
{
public:
  struct ConstCharWrapper
  {
    inline ConstCharWrapper(const char* str) : m_str(str) {}
    const char* m_str;
  };
 
  StringHash(ConstCharWrapper str)
    : m_hash(CalculateFNV(str.m_str))
  {
  }
 
  ME_STRING_HASH_CONSTRUCTOR(1)
  ME_STRING_HASH_CONSTRUCTOR(2)
  ME_STRING_HASH_CONSTRUCTOR(3)
  ME_STRING_HASH_CONSTRUCTOR(4)
 
  // other constructors omitted
};

By making the constructor take a ConstCharWrapper instead of a const char*, we have altered the outcome of the overload resolution process. All constructors taking a reference to an array are now considered better matches by the compiler, because the constructor taking a ConstCharWrapper has to go through one implicit conversion, making the other constructors win in the case of constant strings. Similarly, non-constant strings can only be converted to a ConstCharWrapper implicitly, again disambiguating overload resolution.

Note that in order for this to work the ConstCharWrapper constructor is non-explicit on purpose.

Conclusion

Using the StringHash class introduced above, you can turn run-time hashing of constant strings into quasi compile-time constants without having to change calling code. I say “quasi” because the results of course cannot be used as a true compile-time constant (e.g. in a switch-statement, or as a non-type template argument), but rather relies on the compiler/optimizer instead. Therefore, it should be pointed out that this works in Visual Studio, as well as all major console platforms (Xbox360, PS3, Wii).

In addition, employing this trick reduces the size of the executable, because the constant strings are not used anymore and will therefore never end up in the read-only section of the executable, resulting in maybe a few extra KB of memory to use. This could also be beneficial for other applications making use of the above, e.g. compile-time string encryption, because the source strings are nowhere to be found.

Update: As suggested in the comments, you don’t need to use the preprocessor in order to define different constructors, but can use template meta-programming for that.

One such possible template solution is the following:

template <unsigned int N, unsigned int I>
struct FnvHash
{
  ME_INLINE static unsigned int Hash(const char (&str)[N])
  {
    return (FnvHash<N, I-1>::Hash(str) ^ str[I-1])*16777619u;
  }
};
 
template <unsigned int N>
struct FnvHash<N, 1>
{
  ME_INLINE static unsigned int Hash(const char (&str)[N])
  {
    return (2166136261u ^ str[0])*16777619u;
  }
};
 
class StringHash
{
public:
  template <unsigned int N>
  ME_INLINE StringHash(const char (&str)[N])
    : m_hash(FnvHash<N, N>::Hash(str))
  {
  }
};

Instead of writing several different constructors, we only need one templated constructor for constant strings now. This constructor in turn simply calls the Hash() function of the class template FnvHash. As can be seen, the FnvHash::Hash function just calls itself recursively, working its way from the end of the string to the beginning. The partial template specialization FnvHash<N, 1> serves as a mechanism to end the recursion.

The resulting assembly generated is the same, though it should be noted that the template solution probably is more taxing for the compiler, and depending on the compiler you use, you might have to alter options like inline recursion depth in order to make it work for longer constant strings.

assert() is a very useful tool for ensuring that pre- and post-conditions, as well as invariants, are met upon calling or exiting a function. If you have never used assertions before, start using them now – they will help you find bugs in your own code, and quickly highlight when code is not used in the way originally intended.

What to improve?

There are a few bits missing in the standard assert(). Specifically, the features I miss are the following:

• No way to output a (formatted) message to the user.
• When a debugger is connected, the assert() does not halt execution in the line the assert() fired, but rather somewhere in assert.c. The new assert should trigger a breakpoint at the exact location the assert fired.
• No way to show the values of individual variables used in the condition expression in assert(), only the whole condition is shown.

Consider the following example which will demonstrate the above:

// somewhere in a FIFO implementation, the original assert:
assert(GetSize() < GetCapacity());
 
// an improved assert:
ME_ASSERT(GetSize() < GetCapacity(), "Cannot push another value into an already full FIFO.")(GetSize(), m_end, m_read, m_fillCount);

Using the standard assert(), all you know is that the “Assertion GetSize() < GetCapacity() failed.” If the assert fired on anybody else’s PC, this is not really helpful. How large was the FIFO? What did GetSize() yield? Was the FIFO really empty, or were the internal pointers messed up because of e.g. a memory stomp? All questions unanswered.

What we would like is an improved assert() which is able to fill in those gaps, and provide answers to exactly these questions.

Improved syntax

In order to fulfill the requirements stated above, one possible syntax for the new assert could be the following:

ME_ASSERT(condition, message, optional comma-separated list of message parameters)(optional comma-separated list of variables/values);

As we will see later, this syntax allows us to log variables and their values, trigger a debugger breakpoint in the line the ME_ASSERT macro was written, and does not generate any instructions in a retail build. Let’s take a look at a few examples to see how we would like to use our assertion macro:

ME_ASSERT(m_start + i < m_end, "Item %d cannot be accessed. Subscript out of range.", i)(m_start, m_end, m_allocEnd);
 
ME_ASSERT(from >= std::numeric_limits::min(), "Number to cast exceeds numeric limits.")(from);
 
ME_ASSERT(false, "Key %s could not be found.", key.c_str())();

Before we start worrying about how to put that into a macro, let’s try to come up with the equivalent C++ code first. What we first need is a mechanism which allows us to log a formatted message, and an optional, unlimited number of variables, in that order. Logging itself can be done in any way you want, but the unlimited number of variables needs special treatment. There’s a well-known C++ idiom which achieves something similar, the Named parameter idiom which can be used to initialize (an unlimited amount of) class members in any order. In the same vein, we can use a temporary class instance and call its member functions returning a reference-to-self, which nicely fits the bill for our purposes:

class Assert
{
public:
  // logs a formatted message internally
  Assert(const char* file, int line, const char* format, ...);
 
  Assert& Variable(const char* const name, bool var);
  Assert& Variable(const char* const name, char var);
  Assert& Variable(const char* const name, short var);
  Assert& Variable(const char* const name, int var);
  // more overloads for built-in types...
 
  // generic template
  Assert& Variable(const char* const name, const T& value);
};
 
// example usage
Assert(__FILE__, __LINE__, "Item %d cannot be accessed. Subscript out of range.", i).Variable("m_start", m_start).Variable("m_end", m_end);

In the example above, a temporary instance of the Assert class is created on the stack, and the Variable() member-function can then be used to chain an unlimited number of Variable()-calls together. With this system in place, we can output both a variable’s name and its value for built-in types as well as user-defined types (e.g. Strings, Vectors, etc.). The former will use one of the existing overloads, the latter will use the member function template and assume that the given type either offers a c_str() method or a << stream operator.

Debugger break

Remember that we wanted to trigger a debugger breakpoint in the same line the assert has fired, after all the variable’s states have been logged. Triggering a breakpoint is not too hard by itself:

#if !ME_MASTER
#  define ME_BREAKPOINT (IsDebuggerConnected() ? __debugbreak() : ME_UNUSED(true))
#else
#  define ME_BREAKPOINT ME_UNUSED(true)
#endif

The ME_BREAKPOINT macro triggers a breakpoint if a debugger is connected (IsDebuggerConnected() is a platform-dependent implementation returning whether a debugger is connected or not, e.g. IsDebuggerPresent() on Windows), and does nothing otherwise. Furthermore, the macro evaluates to ME_UNUSED(true) in retail builds, not generating any instructions (as we will see later).

Using the comma operator, we can use the above macro to trigger a breakpoint whenever an assert fires:

Assert(__FILE__, __LINE__, "Item %d cannot be accessed. Subscript out of range.", i).Variable("m_start", m_start).Variable("m_end", m_end), ME_BREAKPOINT;

The comma operator ensures that the temporary Assert’s destructor has been called before the breakpoint is triggered, hence both the formatted message and the variables (and their values) will have been logged already. Of course, one thing we need to make sure is that the temporary Assert instance is created and the breakpoint triggered only if the assert’s condition is not met. This can simply be done by using the conditional (?:) operator, like in the following example:

(m_start + i < m_end) ? (void)true : (Assert(__FILE__, __LINE__, "Item %d cannot be accessed. Subscript out of range.", i).Variable("m_start", m_start).Variable("m_end", m_end), ME_BREAKPOINT);

Note the extra parentheses before the Assert and after the breakpoint! Without these, the ME_BREAKPOINT statement would not be part of the second conditional operand, but rather be its own statement – meaning that a breakpoint would always be triggered, no matter if the condition was met or not (due to the operator precedence of the conditional operator and the comma operator).

Of course we don’t want users of the new assert to write code like this – it is much too error-prone and lengthy. Furthermore, we cannot eliminate the unneccessary code in retail builds without manual user intervention. Macros to the rescue!

Stuffing everything into a macro

Putting everything into a macro requires quite some preprocessor magic, which we’ll try to tackle now. First, let’s try to stuff the left part of the example above into a macro:

#define ME_ASSERT(condition, format, ...) (condition) ? (void)true : Assert(__FILE__, __LINE__, "Assertion \"" #condition "\" failed. " format, __VA_ARGS__)

As you can surely see, this will expand into the following:

// macro
ME_ASSERT(m_start + i < m_end, "Item %d cannot be accessed. Subscript out of range.", i);
 
// expansion
(m_start + i < m_end) ? (void)true : Assert(__FILE__, __LINE__, "Assertion \" m_start + i < m_end \" failed. Item %d cannot be accessed. Subscript out of range.", i);

Stuffing the optional list of variables into a macro is admittedly somewhat harder. Because of supporting printf-style formatted messages, our macro already is variadic (note the … as macro parameter), so how can we offer an additional, variable number of arguments? The following clearly doesn’t work:

#define ME_ASSERT(condition, format, ..., ...) // huh?

There’s no way to distinguish where one list of arguments ends, and where the next starts. That is, a variable number of arguments (…) must always be the last argument to a macro. But, by introducing an additional pair of parentheses, we can “start” the expansion of any other (variadic) macro, because you can think of the preprocessor running multiple passes as long as new function macros are detected. A simple example will show what I’m talking about:

#define SIMPLE_MACRO(format, ...) Assert(format, __VA_ARGS__) ANOTHER_MACRO
#define ANOTHER_MACRO(...) // doing something with __VA_ARGS__

Putting on our preprocessor hat, we can see that the following happens:

• In the first pass, SIMPLE_MACRO() gets expanded into some source code, ending in ANOTHER_MACRO. So if you write “SIMPLE_MACRO(foo, bar, a, b, c)()” (note the parentheses), it will get expanded into “Assert(foo, bar, a, b, c) ANOTHER_MACRO()”.
• In the second pass, the preprocessor finds ANOTHER_MACRO() and recognizes it as another function macro. Hence, you can put a variable number of arguments into the parentheses, and they will be the arguments to the ANOTHER_MACRO macro.

This way, we can have a variable number of arguments to the formatted message, and a variable number of arguments for our list of variables. But still, we need a macro which expands every single argument of a __VA_ARGS__ parameter into whatever we want. Specifically, we want to turn

(a, b, c)

into

.Variable("a", a).Variable("b", b).Variable("c", c)

This would allow us to expand the list of variables into .Variable()-calls on the temporary Assert instance.

Excursion: A journey into preprocessor land

In order to get the job done, what we first need is a macro which expands the given arguments into an operation, called with the correct arguments. Something like the following does the trick:

#define ME_PP_EXPAND_ARGS_1(op, a1) op(a1)
#define ME_PP_EXPAND_ARGS_2(op, a1, a2) op(a1) op(a2)
#define ME_PP_EXPAND_ARGS_3(op, a1, a2, a3) op(a1) op(a2) op(a3)
#define ME_PP_EXPAND_ARGS_4(op, a1, a2, a3, a4) op(a1) op(a2) op(a3) op(a4)
// other macros omitted...

This works, but assumes that the caller already knows the amount of arguments provided. What we need is a variadic macro, which dispatches to any of the above macros depending on the number of arguments given. This can be done by first counting the number of arguments (using a separate macro), and then combining the result with the name of the macro – an example will make it clear:

// variadic macro "dispatching" the arguments to the correct macro.
#define ME_PP_EXPAND_ARGS(op, ...) ME_PP_JOIN(ME_PP_EXPAND_ARGS_, ME_PP_NUM_ARGS(__VA_ARGS__)) ME_PP_PASS_ARGS(op, __VA_ARGS__)

Ok, let us try to decipher the above step by step, by assuming that we used the macro like this: ME_PP_EXPAND_ARGS(op, a, b)

• ME_PP_NUM_ARGS is the macro which “counts” the number of arguments given, and yields 2 in this case. An example of how such a macro can be implemented can be found here.
• ME_PP_JOIN is a simple macro which joins two arguments, by “stitching” them together. In the example above, the result would be ME_PP_EXPAND_ARGS_2 (note the underscore at the end of the first argument), which in turn is a macro itself!
• ME_PP_PASS_ARGS is used to pass the given macro arguments to the ME_PP_EXPAND_ARGS_2 macro (working around preprocessor bugs in Visual Studio).
• Finally, the resulting ME_PP_EXPAND_ARGS_2(op, __VA_ARGS__) is expanded once again by the preprocessor.

Note that the argument op can be a macro itself! With the above in place, we can turn the arguments “(a, b, c)” into “.Variable(“a”, a).Variable(“b”, b).Variable(“c”, c) using the following:

#define ME_ASSERT(condition, format, ...) (condition) ? ME_UNUSED(true) : (Assert(__FILE__, __LINE__, "Assertion \"" #condition "\" failed. " format, __VA_ARGS__) ME_ASSERT_IMPL_VARS
 
#define ME_ASSERT_IMPL_VARS(...) ME_PP_EXPAND_ARGS ME_PP_PASS_ARGS(ME_ASSERT_IMPL_VAR, __VA_ARGS__), ME_BREAKPOINT)
 
#define ME_ASSERT_IMPL_VAR(variable) .Variable(#variable, variable)

Again, ME_ASSERT() is a variadic macro ending in ME_ASSERT_IMPL_VARS, which in turn is a variadic macro itself. ME_ASSERT_IMPL_VARS expands and forwards the given arguments to ME_ASSERT_IMPL_VAR(), which is exactly what we use for automatically expanding our list of variables into Variable()-calls on the temporary Assert instance.

Finally, we can use our improved assertion facility. The following shows the output of an assertion which fired:

ME_ASSERT(m_start + i < m_end, "Item %d cannot be accessed. Subscript out of range.", i)(m_start, m_end, m_allocEnd);

Array.inl(146): [Assert] Assertion "m_start + i < m_end" failed. Item 10 cannot be accessed. Subscript out of range.
Array.inl(146): [Assert]   o Variable m_start = 0x2260608 (pointer)
Array.inl(146): [Assert]   o Variable m_end = 0x2260608 (pointer)
Array.inl(146): [Assert]   o Variable m_allocEnd = 0x2260630 (pointer)
molecule_core_d.exe has triggered a breakpoint

And a debugger breakpoint will conveniently halt execution at Array.inl(146).

Retail builds

The last piece of the puzzle still missing is how to get rid of all the extra code in retail builds. Most C/C++ programmers know about the following trick, which is e.g. used for silencing compiler warnings about unused variables:

// i is unused
int i = 10;
(void)i;

You can combine this trick with the sizeof() operator, and have the compiler accept every possible, legal expression in C++ without generating any instructions at all, because sizeof() will always be evaluated at compile-time. This means that something like

(void)sizeof(a < b);

will never generate any instructions in the executable. (Ab)using the sizeof() operator this way, we can simply change our ME_ASSERT macro to behave as follows in retail builds:

#define ME_ASSERT(condition, format, ...)	ME_UNUSED(condition), ME_UNUSED(format), ME_UNUSED(__VA_ARGS__), ME_UNUSED

ME_UNUSED is a macro employing the trick stated above, turning all given arguments into an “empty” statement. Hence, in retail builds, all arguments to the assert as well as the list of variables will expand into pure “nothingness”:

// macro
ME_ASSERT(m_start + i < m_end, "Item %d cannot be accessed. Subscript out of range.", i)(m_start, m_end, m_allocEnd);
 
// expanded
(void)sizeof(m_start + i < m_end), (void)sizeof("Item %d cannot be accessed. Subscript out of range."), (void)sizeof(i), (void)sizeof(m_start), (void)sizeof(m_end), (void)sizeof(m_allocEnd);

This also makes sure that the compiler will not warn about any unused local variables or similar, which is a nice side effect.

Performance

One thing we haven’t talked about yet is performance. Debug builds have a tendency to become slower during development anyway, so we should make sure that our improved assert doesn’t totally kill peformance.

It should be quite clear that each ME_ASSERT can only have two outcomes – either the assert fires, or it doesn’t. We’re not so much concerned about performance in the former case, because when an assert fires, the amount of cycles/instructions it needed don’t really matter. But we should take a closer look at the performance of non-triggered asserts.

 
Non-optimized, debug builds

Again, let’s work on an example by using on of the heavier asserts introduced before:

ME_ASSERT(m_start + i < m_end, "Item %d cannot be accessed. Subscript out of range.", i)(m_start, m_end, m_allocEnd);

The generated assembly (Visual Studio 2010 SP1, x86) will look something like the following:

012F7B50  mov         eax,dword ptr [this]  
012F7B53  mov         ecx,dword ptr [eax+4]  
012F7B56  mov         edx,dword ptr [i]  
012F7B59  lea         eax,[ecx+edx*4]  
012F7B5C  mov         ecx,dword ptr [this]  
012F7B5F  cmp         eax,dword ptr [ecx+8]  
012F7B62  jae         core::Array::operator[]+39h (12F7B69h)  
012F7B64  jmp         core::Array::operator[]+0DBh (12F7C0Bh)
012F7B69  
  lots of instructions omitted:
    setting up parameters
    pushing offsets to strings (e.g. "Assertion "m_start + i < m_end" failed.") onto the stack
    calling the Assert constructor
    calling Assert::Variable
    calling IsDebuggerConnected
012F7C0A  int         3
012F7C0B  mov         edx,dword ptr [this]  
  rest of code

Don’t worry, there’s no need to completely understand all of the above. The important things are the following:

• The first instructions load m_start and m_end from memory (those are member variables).
• The cmp and subsequent jae/jmp instructions carry out the comparison (m_start +i < m_end).
• If the condition is not true, the next instruction to be executed is at address 012F7B69.
• If the condition is true, the next instruction to be executed is at address 012F7C0B.

So in the case of the assert not firing, there’s some loads, a compare, and a jump instruction to execute. That’s not too much instruction-wise, but the code has to jump over a lot of instructions not executed (about 160 bytes), which will cause instruction-cache misses. If that causes too big a performance hit, one possible solution is to use somewhat more light-weight asserts deep inside your codebase, e.g. in leaf functions which get called a lot.

A possible implementation of such a light-weight assert could be the following:

#define ME_LIGHTWEIGHT_ASSERT(cond)		(cond) ? true : __debugbreak()

This is about as simple as it gets, and it will only ever do a comparison (and any loads needed), and a jump. The pattern to look for in the assembly code would then look like this:

cmp         this,that
jne         fire 
jmp         nofire
fire:       
  int 3 
nofire:
  rest of code

__debugbreak is an intrinsic function available in Visual Studio which generates the int 3 instruction, which in turn triggers a breakpoint inside the debugger. Similar functions/instructions exist on PowerPC as well, therefore such a light-weight assert can be built for any console platform as well.

 
Optimized builds

Even though the compiler is smarter in optimized builds and manages to eliminate some unnecessary memory loads, the code for calling the assert constructor, setting up parameters and everything still takes about 100 bytes, so instruction-cache misses will likely be caused in those builds as well. Again, the light-weight assert can be of help here – in optimized builds, the compiler will be smart enough to get rid of one of the jmp instructions, generating even less code.

Static asserts

Another thing worth mentioning is that this post only enhanced run-time asserts. There’s another type of assertions, so-called static or compile-time asserts. The new C++11 standard defines the static_assert keyword for that purpose, and Visual Studio 2010 and GCC already support it.

On other compilers, you can build your own static asserts using some template magic (found in the book “Modern C++” by Andrei Alexandrescu), or compiler-dependent features.

Download

The complete assert implementation can be downloaded here (released under the zlib license), and comes with the following:

• General preprocessor stuff like ME_PP_IF and ME_PP_TO_BOOL.
• ME_JOIN macro to concatenate two tokens, even when the tokens are macros themselves.
• ME_PP_IS_EMPTY macro for checking whether a variadic macro had an empty argument list or not.
• ME_PP_NUM_ARGS macro for counting the number of arguments to a variadic macro.
• ME_PP_EXPAND_ARGS macro for expanding an arbitrary amount of arguments into an operation, called with the correct arguments.
• ME_UNUSED macro for turning any legal C++ expression into nothing, not generating any instructions.
• ME_BREAKPOINT macro for triggering a breakpoint when a debugger is attached.
• ME_ASSERT macro as described above, along with a simple implementation of the Assert class.

Word of warning: most of the preprocessor magic is not for the faint of heart.

(This post is a more detailed cross-post of this blog entry).

Early addictions

It all started more than 20 years ago, when my father introduced me to video gaming on the ColecoVision console at the age of 5 or so – I still have fond memories of playing Mouse Trap, Donkey Kong, and Pitfall on our old TV. Because games were so expensive back then (around ~100€ nowadays, not taking into account inflation!), my family used to buy games only twice or three times a year, leaving us with an incredible collection of about 8 games. Still, we used to play them whenever we were allowed to.

Arrival of the C64

One or two years later, my father invested his money in our first computer – the Commodore 64. Ah, the C64!

Not only did it feature a vast collection of games, it also made it possible to copy games (piracy was a big problem) – there weren’t many legal retailers around in Austria at that time, so we more or less had to get them by copying from somebody. Turned out my father knew a few people, so we ended up playing tons of games. Even though it’s been more than 20 years ago, thinking of some of the games and especially some of the SID chiptunes gives me goosebumps. Everybody of us put up with loading times somewhere around 10 mins. (possibly more) for larger games on the datasette, simply because the games were great. What a machine the C64 was, I loved it!

In addition to having a great collection of games, you could also write and run BASIC programs on the C64. Before even knowing what BASIC and programming in general was all about, my father introduced me to LOGO (which supported turtle graphics!), which must have been my very first contact with a simple programming language. Not long after figuring out how to draw simple snow-flakes using the turtle and its “turn-left”, “move-forward”, “turn-right” commands, I got introduced to BASIC.

Even though I was not able to grasp high-level concepts like for-loops and GOSUBs at that age, I remember that writing very simple BASIC programs was a lot of fun, and I used to sneak into my parents’ bedroom when they weren’t around, just to use the C64. More often than not, I was trying to recreate simple stuff I had seen in other games, just to figure out how you could actually do something like that. Of course I had no idea how to use sprites, or what the C64′s architecture was all about, but getting the computer to do something I wanted was so enthralling.

Baby steps in programming

A few years later, my father spent an awful lot of money on our first PC – a 386 with 33MHz. We used to play all-time classics like Wing Commander, Syndicate, UFO, and Doom – and invite people to our home, in order to participate in nights full of Doom deathmatches. I still remember how much I admired people working in the games industry, and I knew that being a game developer working on such a game would be like a dream come true for me. We still used to play games on the C64, but the PC was able to do so much more, so it attracted my attention. Around that time, my older brother began programming using Turbo Pascal for MSDOS, so naturally I wanted to learn as much as possible about PC programming, bothering him with questions endlessly.

That’s when one day I got introduced to the PC demo scene.

This must have been the point which sparked my thirst for low-level programming, hardware details, working at the assembly level, and getting the most out of any hardware. I just didn’t believe how something like Second Reality or Crystal Dream 2 was possible on my father’s poor 386 (those demos have to be one of the best demos ever made, and will always be remembered by me). I was stoked. I wanted to know every little detail about texture mapping, 3d algorithms, and mode 13h programming. But I didn’t know where to start. Luckily, my brother was already in college, and helped me learn a lot about vectors and matrices, some assembly, and programming in general.

Education

I soon went to college (called HTL here in Austria) myself, and slowly started to learn C/C++ in my spare time – surprisingly, we were never really taught any programming language in school (except for a bit of Pascal), which is kind of uncommon for a college specialized in engineering. At that time, I was still tinkering around with texture mapping and the likes, but never really got that far with my own game. I was always more impressed with technological stuff, technical articles I read on the internet. All that mumbo-jumbo about 3d graphics and complicated sounding stuff just made it so much more interesting. I was addicted to technology and low-level details.

After having finished college, I knew that I didn’t want to go back to engineering, because somehow that topic lost its appeal over the years. Not really knowing what and where to study, I came upon a computer science master’s program at the Vienna University of Technology, so I ended up moving to Vienna and studying Computer Graphics & Digital Image Processing there.

First payoff

In retrospective, some of the stuff I was taught at university wasn’t the stuff I expected (to say the least), but some of it paved my way into the games industry. It was in the third semester of the Bachelor’s program where groups of students had to program their own 3d game using OpenGL. I knew that this was my chance to enhance my skills, and learn some state-of-the-art 3d programming. And of couse I was thrilled by the idea that we could write a game and actually get a grade for it, that I put lots and lots of time into it. In the end, our game ended up getting the “Best Game of 2004” award!

Later that year during summer, I contacted one of the guys I knew from university who was working for a local game development studio (the Austrian game development scene is very, very small), and asked whether his employer was offering internships. It turned out that this guy was no longer working for said company, so he wasn’t aware of any internships. But he told me he could maybe arrange a job interview at his current employer if I’d be interested. Well, of course I was, so I took the chance, showed them my portfolio, showed them the game we did at university, and started work the next monday. After all those years, that’s how I ended up in the games industry.

Fast forward

In the last 7 years, I’ve learned a lot about programming during my time in the industry. I’ve worked with some very talented, passionate and creative people. And even though I have been through times of crunch where I had to put in more than 100 hours a week, I can whole-heartedly recommend the industry as a great place to work with like-minded people. Joining the games industry has been one of the best decisions in my life, and it has always been a dream of mine.