Inclusion Guards

Just to clear up what we’re talking about, an inclusion guard looks like this:

#ifndef HEADER_FILE_H
#define HEADER_H

...//your header

#endif //HEADER_FILE_H

It consists of three preprocessor directives around the code of your header file.

Most IDEs add these for you automatically when you create a header, but it’s well worth having an appreciation of why they are there.

An inclusion guard simply stops your header file being included more than once in any program at compilation time.

I’ve already talked about how the preprocessor effectively copies an included header into a source file, so you can see immediately why you might want to prevent this from happening, even if it is for no other reason than to keep your compilation time down and your executable smaller!

The other reason you should use them is because they prevent you running into errors like this:

In file included from <file>.h:8:0,
from <file>.h:12,
from <file>.h:14,
from <file>.cpp:14:
<file>.h:16:7: error: previous definition of 'class ThisClass'

When you’re working on a small program with only a couple of files, you might be tempted to think you can skip using them, especially if you’re generating everything by hand. However, small programs don’t take long to grow, so for all but the simplest of cases, use inclusion guards. They will save you hours of time trying to work out an include tree that doesn’t result in the errors above.

What name should I use?

The simplest method (and the conventional one) is to use the capitalised name of the header file, changing the dot to an underscore. So MyClass.h will be MYCLASS_H (that’s an example – you’d never actually call a class MyClass, right?).

What about #pragma once?

#pragma once tells the compiler to only include a header once, so it effectively does the same job. But, as I mentioned before, pragmas are preprocessor directives that are specific to your compiler, so you shouldn’t depend on them. In fact, pragma once is now obsolete in gcc.

Why?

Well, firstly, you’re relying on a compiler to implement something you can effectively do quite simply yourself. Your next compiler might not do the job the same way (see below), or even at all, which would mean more work for you further down the line.

Secondly, how will the compiler ensure that you aren’t including the same file twice without a #define? It will have to judge by filename, or inode, or some other comparative algorithm to prevent duplicate inclusion. This is quite a difficult task – symbolic links and mounted filesystems can slip through this kind of detection and result in the exact errors that you are trying to avoid.

The beauty of inclusion guards is that they are 100% portable and 100% supported.

Anything else I need to know?

Nope. Just remember that your guards go outside ALL the content in your header, including other includes.

Hmm.

What I mean is: make sure your #include directives in your header appear inside the inclusion guard.

Then you’ll never have to worry about a circular include again.



Debug ncurses Application With GDB And Full Input Output

Actually, you can use this technique to debug any kind of console app where debugging on the command line interferes with the program’s output. It’s quick and easy, and unlike attaching to a running process in another shell, it allows you to debug as soon as the program starts, meaning you can catch even those fiddly bugs that only appear during set up.

If you’ve ever tried to debug an ncurses application, you’ll know how problematic it can be.

Using printf statements makes a mess of your visual output…

Debuggers get the keyboard input all mixed up in the shell…

Eugh. HEADACHE!

There is a way to seamlessly debug your ncurses application and it is probably easier than you realised.

Enter gdbserver.

Read More »



What Does The Preprocessor Do?

What a jolly good question.

The preprocessor takes a look at your source code just before it goes off to the compiler, does a little formatting, and carries out any instructions you have given it.

Like what?

Well, preprocessor instructions are called preprocessor directives, and they all start with a #.

Like #include?

Exactly.

Each # command that the preprocessor encounters results in a modification to the source code in some way. Let’s take a look at them briefly in turn, and then we’ll see what goes on behind the scenes.

Read More »



CyberTalk Flash Fiction 2014 Winner

cybertalk6I won!

How cool is that??

If you want to read my cyber-themed science fiction story, it’s now available on the SoftBox website.

CyberTalk is produced in conjunction with the Cyber Security Centre at De Montfort University Leicester, and you can read all the issues online (or subscribe for a print copy!).