Question

This question is one of several that discuss naming conventions for C++ include guards. The person asking that question thinks that this naming convention:

#ifndef FOO_H
#define FOO_H

// ...

#endif

is a bit non-intuitive when taken by itself (what does FOO_H mean?) and I tend to agree.

Others say that, barring the need to add more stuff for better collision avoidance (like PROJECTNAME_FOO_H_SDFFGH69876GF), the name FOO_H is just fine because it’s clear from its context what its purpose is (namely, it’s at the beginning of the files of the same name and it’s clear that it’s an include guard).

I could buy this if the only purpose of having FOO_H would be to guard against multiple inclusion, but are there conditions for which I’d want to have FOO_H elsewhere in the files? I’d think conditional compilation would be a good reason, in which case naming it something like FOO_H_INCLUDED would be clearer.

Are there straightfoward uses akin to this, or should I avoid repurposing the include guards?

Answer 1

I think the question is flawed in itself. The term include guards refers to #defines and checks for #defined in the particular use of guarding against multiple inclusion, which is as much to say that is the only use for that.

Now taken a little more generally, defines and conditional compilation can be used for other things, like writing bits of code that are platform dependent and will only get compiled under some circumstances…

Whether FOO_H or FOO_H_INCLUDED is better, I will always say that the later is the most expressive, and then I will go back to vi and type FOO_H in my next foo.h header. Again, as I mentioned in a comment on the other question, you grow used to the pattern:

#ifndef XXXXXXXXX
#define XXXXXXXXX

#endif

as the first two and last line in a file and you end noticing. That is until it bites back if you have reused the same name…