Sunday, June 19, 2016

In last month’s post I mentioned that in my opinion, the holy grail of programming is C with classes. There is something incredibly fun about programming in C that other languages just don’t have, but I will admit that what it is missing are classes. You can work around this by using structs and function pointers, but it’s just … not the same.
There is of course C++, the one true successor to C that adds classes. We are now dealing with instances, references, namespaces and what not. Writing clean C++ code is often an exercise in what I call “keeping the compiler happy.” So Brian (pictured on the right) and me decided to start using it in a more hackish way, if only to put the fun back in C.

So, I’m working on this project, and the codebase quickly grew to a couple of thousand lines of code. Nothing special there, as even hobby projects are easily 10k LoC or 50k LoC or more. My aging computer is taking longer and longer to build the code, up to the point where I just wish I had a C++ interpreter rather than a compiler.

“My code is compiling.”

The idea of C/C++ is that you write multiple translation units and compile those into object files. The header files just have declarations, the C source files contain the implementation. The linker will combine the object files to create the final executable. Rebuilding a project should be fast because only those objects for which you changed code need recompilation. In practice, it takes quite some work to get the job done. On top of that, in C++ the headers contain lots of code because of templated classes. All those headers need to be parsed and compiled over and again. Building becomes a chore, even if you only include what you truly need.

Enter the “unity build” system. Also known as a major hack, unity builds bring compile times back from minutes to near instant at best, and seconds at worst. How is this possible? That endless stream of C++ headers, we are only going to build that once. Even on my aging computer, the compiler is surprisingly fast at doing stuff only once.

How to setup a unity build system

For a unity build, we are not going to write any traditional header files. Writing header files is just a chore, and considered a waste of time as they don’t serve any real purpose in a unity build system. Instead, if you need a struct or class, just put it in the top of the .c or .cpp source file. Any typedefs global to the project may go into a single header named types.h, but unlike traditional C, these headers are never included in every source file. No need to worry about any standard includes either; just write straight C code into the unit. Each unit is included into a master file for the project. That master file is the only file that is fed to the compiler, and it will build surprisingly fast.

// master.c

#include <stdlib.h>
#include <stdio.h>

#include "types.h"

#include "debug.c"
#include "mycode.c"
#include "main.c"

// end

The easiest way of using a unity build system is for new projects. Converting existing codes can be tricky. A reason for this is that the order of includes is more important than ever, and there are no include guards. Another reason is that all static symbols now appear in a single flattened namespace. You can’t use static at the unit level in a unity build system. Choose your (static) symbol names wisely; prefix them with the unit name, for instance.

The unity build system doesn’t help in creating reusable code. It is for this reason that schooled C programmers say it’s a total hack job. That may be so, but it is a complete joy to bang in make and instantly see the shell prompt return—ready to run that code and take it for a test drive. It gives a spin to C, nearly turning it into a scripting language.

It puts the fun back in C. Maybe we’re not supposed to do it this way, but maybe that’s why it’s so much fun.