Geas Home | Play the Game

1.3.1 The #include statement

This is by far the most used preprocessor command. It simply tells the preprocessor to replace that line with the contents of an entire other file before going any further.

Data you put in include-files is usually data that won't ever change and that you want to put into several files. Instead of having to write those same lines over and over with the cumulative chance of putting in copying errors as you go, you simply collect that data into one or more files and include them into the program files as necessary.

The syntax is very easy:

#include <standard_file> #include "special_file"

NB! Note the absence of a ; after the line!

The two different ways you write this depend on where the file you want to include exists. There's a number of standard include files in the game, spread around in a number of different directories. Rather than having to remember exactly where they are, you can just give the name of the file you want to include then.

#include <stdproperties.h> #include <adverbs.h>

If you want to include files that aren't part of the standard setup, for example files of your own, you have to specify where they are. You do that either relative to the position of the file that uses it or by an absolute path.

#include "/d/Genesis/login/login.h" #include "my_defs.h" #include "/sys/adverbs.h" // Same as the shorter one above

When you include standard files, always use the <>-path notation. The reason isn't only that it becomes shorter and easier to distinguish but also that if the files move around your program will stop working. If you use the <>-notation they will always be found anyway.

Include files can have any name, but as a rule they are given the '.h' suffix to clearly distinguish them as include files.

It is even possible to include c-files, i.e. to include entire files full of code. However, doing that is very bad form. Do not do that EVER! Why? Well, since you include the uncompiled code into several different objects, you will waste memory and CPU since these identical included parts has to be compiled and stored separately for each object that uses them. Apart from all this just reading the code will be a chore better not even contemplated.

What has the extension of the file name really to do with the contents then? Well... actually nothing at all. However, the convention is to keep code, functions that are to be executed, in c-files and definitions in h-files. Usually the mudlib reflects on this convention and might not recognize anything but c-files as code sources.