Building = Preprocessing + Compiling + Linking

After answering the same questions over and over and over and over again especially about compiling and linking, I thought it might be time to write down a few things, that I and maybe others could point to instead of keep repeating ourselves in the future. Given the wideness topic I’ll be writing things down in multiple parts. In this first post I’ll be explaining a few basic terms and their practical applications, the next one will go more into details on how linking against external libraries work and in the third and last part I’ll be writing down answers to some common issues. I hope this will turn out as a timesaver for all parties. – As a disclaimer I should add, that I’m a human being that makes mistakes and can have wrong models in their mind, thus if I make a mistake feel free to point them out.

Part I - Building, Compiling, Linking

Part I – Terms and Explanations

Although this should essentially be covered in any basic programming book, even the bad ones, here we go with a few “definitions”:

Application

Looking at it in a very abstract way, an application is no different than anything else on your hard disk, because it’s just ones and zeroes, the important part however is how these numbers get interpreted. Your CPU (the heart & brain of your PC) doesn’t understand the ones and zeroes from a music file, but if you give it the data of an application it can translate them into actions that will do what the programmer intended to (hopefully).

Building

To get such an application, your C++ code has to be turned into ones and zeroes, also known as machine code. The full processes of doing so is called building and is as such more an abstract term, because the process is essentially a composition of mainly three sub-processes: Preprocessing, compiling and linking.

Header File (*.hpp / *.h)

If you’ve done your job right, i.e. followed the correct way of writing code, then you should have all the declarations of functions, classes, structs, enumerates, templates, etc. in header files. With the help of a header file, the compiler will know how much stack and memory space is needed for the machine code that is about to be generated.

Source File (*.cpp)

The source file holds most of the implementation details, also known as code definitions. It’s where the behavior of the application itself is crated, meaning how the declared classes and functions interact with each other.

Inline File (*.inl)

This is not always needed and essentially optional, but it’s a common and good practice to put code definitions, that are required to be in the header file, into an external file and include it at the needed position in the header file. The most common use of inline files is for template definitions, which need to be in the header given that they get executed at compile time and can influence the memory layout and footprint.

Preprocessing

Before your code gets translated into anything the preprocessor will kick-in. All the statements that start with a number sign are actually preprocessor directives and get resolved in the first step of building an application, for example all the #include will get replaced with the actual content of the included header file or for any #define X Z all X will get replaced with Z or any kind of macro will get executed.

Compiling

Now that one source file will hold all required declarations the compilation can begin. Compiling is one of the terms that confuses a lot of people since it’s often used synonymously to building, which in turn isn’t too surprising given that compiling is the most crucial part, since it actually translates all the source into machine code. But you don’t end up with an application itself, but instead you end up with an object file for each source file.

Object File (*.o / *.obj)

Object files contain the translated source code in machine code. While the CPU essentially would understand the commands of the binary data, it would not know where to start exactly and miss other referenced code pieces. Thus these object files are only the building blocks used by the linker to generate the final executable.

Linking

As pointed out above the linker will be combining the object files generate by the compiler. It’s called linking because it obviously doesn’t just append or prepend the files, but actually makes “smart” links between parts of the object files – for details you might want to refer to a linker manual or other sources. But the linker doesn’t just link object files, it also links in libraries and it’s here where the difference between static and dynamic libraries are important, but I’ll go into more details in the next part, for now I’ll just say that static libraries are actually just archives of object files and thus can be linked in directly, while for dynamic libraries one just specify the interface and the “connection” between the application and the external code will be made at runtime.

Integrated Development Environments

This essentially doesn’t have anything to do with building applications, but it’s exactly that point that gets confused often. Integrated Development Environments short IDE are simply a set of tools created to work nicely (integrated) together and assist the programmer in creating code. A compiler and a linker can be considered part of this tool set, but it’s not the IDE that builds anything. Some of the most common IDEs would be Visual Studio, Code::Blocks, Qt Creator and Xcode. However one exception remains and that is, the Visual Studio compiler doesn’t really have a name of its own. Sometimes one refers to it as MSVC (Microsoft Visual C++), which in turn could also mean the IDE itself. What’s certain is, that one should not use “I built this game with Code::Blocks”, but instead “I built this game with MinGW” or “GCC”.

Final Thoughts

Having reached the end of the first part, I hope this basic information will be of some help to new beginners and depending on the response or future experience, I might add one or two paragraphs. The second part already has some words written for, so stay tuned!

What I’ve been up to

Where are the SFML News? Where are the Nightlybuilds? Where is eXpl0it3r? Those or other question might some have asked themselves or even me. Of course all the awesome people at the SFML IRC channel know that I never left. There have been quite a few changes in my personal life as well as in my “digital” one. After failing the base exam for computer science at the well-known ETH Zürich, I’m currently aiming for a more practical university, but to get in, I’m doing an internship at the moment. Luckily I’m able to do the internship for a company as a programmer, unfortunately it’s web development thus no C++. With that change my focus in programming shifted slightly away from SFML and C++ itself and I started to dig deeper into the world of PHP. Yes, I can hear all you all scream back there, but I’ve never been an anti-PHP guy and while I see the flaws, it’s still a simple and effective language to work with. I won’t go further into detail what I’m currently working on for my internship, but many things that do there, start to bubble up in other web projects that finally get some more attention (again).

SFML Projects

Some might know that there has already been attempts on this in the past and as a fact, the domain itself has been registered over a year now. I’m talking about this domain: http://sfmlprojects.org/
Currently there’s not much to see, but I’ve decided to go the open source way and not try to hide as much as possible. I’ve already gotten a bit of help by zsbzsb and a few pointers by veltas, other than that the project is still in my hands. The only thing I can do, is to encourage people to look at the current development state and open tickets as well as creating pull requests on the official GitHub repository.

For those that still haven’t look at it: The main idea behind it came from the fact, that there are so many nice projects that simply die in the depth of the SFML forum project section and if that happens, chances are high that the linked binaries will sooner or later get lost as well. To prevent all of this, SFML Projects should enable users to create projects and add various types of content that won’t get taken down after a few days. Next to that the site will automatically promote SFML itself, by showcasing what people have created already with it.

It is and will the longer the more be an interesting journey, thus if you like to help in anyway, don’t hesitate to contact me or tweet us @SFMLProjects.

Kohana & Modules

For the things at work and for SFML Projects, I’m currently using the very light PHP framework called Kohana. Coming from some rather basic PHP background, all this new stuff was and still is slightly overwhelming, but it’s slowly starting to grow on me. Kohana if I remember correctly was originally a clone or rewrite of CodeIgniter and when looking at the basics, the similarities reveal themselves rather quickly.

While starting a few times over with the whole project, I noticed, that it would be easier to create a repository with all the “normal” and boring setup things included and thus KOstart was born. KOstart is basically Kohana with only the needed and additional modules and already includes Bootstrap.

Since the latest Kohana version lacks a non-ORM auth driver, I’ve started to write one and create a module repository just today, which you can find on my GitHub page as well. It currently misses role management, but that should get added pretty soon.

Firefall & RAWR

Quite a big chunk of my free-time, I’ve spent with an MMO FPS called Firefall, which is currently still in its Beta phase. The game is awesome and pulls you in quickly, unfortunately recent changes to the basic systems in combination with the lack of new content, made it a bit less fun for me.

After some ups and downs I’ve been “elected” as the commander of the RAWR army, for which I’ve been creating and maintaining the Live Resource Feed. For RAWR I’m currently also working on a fresh website, but it’s based on Drupal for simplicity reasons. Things are still in development and I feel a bit bad to not having worked on for a while now.

Firefall is not only fun, because of the game content, but because their whole UI is written in Lua and thus moddable. Thus I ended up combining the game with my C++ knowledge and we ended up with SecondaryMap, which as its name says, is a map for your secondary monitor, so you can keep track of your own position and the position of events around you. It’s pretty awesome that this small application uses SFML, Thor and SFNUL – all very nice projects.

SFML Game Jam 2

Before I close this blog post, I just want to mention that the second SFML Game Jam has been held a few weeks ago and as last time, we’ve gotten quite a few awesome games. Originally Jebbs wanted to create a website, but then he had some time issues and zsbzsb took over that burden and create this awesome little site where you can also find all the games of the jam.

Also don’t forget to checkout the game A Temporary Outbreak Nexus and I did for the jam, while both being on quite some time constraint.

Final Thoughts

With that said, I hope to be post a bit more here once again, but if you want to stay updated more often, you might want to follow my Twitter account @DarkCisum. Ever since Grimshaw created that one forum thread, Twitter started to be a very interesting place for getting information. I hope to get some more time at some point for all the nice things like SFML News, but currently I’m just too busy with all my other projects. However as always, don’t hesitate to contact me if you have any questions.