Header file multiple inclusion question

I understand about the whole

Blah.h

Code:

---


ifndef BLAH_H
#define BLAH_H


/* code*/

#endif

---

Then when you want to include Blah. you do:

Code:

---

#include "Blah.h"

---

So now you won't include the same file twice. But I was reading online and saw that it was better (faster compilation times) to do it this way. Something about the compiler lexical analyzer being the most expensive part of the compilation process (Sorry, I can't find the link anymore).

Code:

---


#ifndef BLAH_H
#include "Blah.h"
#endif

---

Where you want the Blah.h file included. Have you guys heard of this? If so, is it worth it to go through a project that takes 3-5 minutes to compile to change all of them?

I can't see how that could make much of a difference, but if you really feel like making a ton of changes, you could find out if it does actually make a difference. I think it's pretty bad programming practice to do it that way though.
You might want to see if your compiler supports pre-compiled headers.

Quote:

---

If so, is it worth it to go through a project that takes 3-5 minutes to compile to change all of them?

---

Having to work with several projects of about 1000-2000 files in each... No... I prefer to have Header guards once in one place... there is enough headake to struggle with other issues

Quote:

---

Originally Posted by Loctan

But I was reading online and saw that it was better (faster compilation times) to do it this way. Something about the compiler lexical analyzer being the most expensive part of the compilation process (Sorry, I can't find the link anymore).

---

This sort of thing really depends on the implementation of the compiler (or, more accurately, the preprocessor).

Some older preprocessors would parse an #include'd file completely, which essentially meant that the whole file had to be read in to detect include guards within that file, and that the file would be read multiple times if it was #include'd multiple times. Putting the include guard into the including file basically reduced the need to execute the #include directive. Some vendors claimed the issue was with the lexical analyser, which is true but misleading: the real issue was that those compilers implemented workarounds for some of the preprocessor inefficiencies in the subsequent lexical analysis phase.

More modern preprocessors are a little smarter than those older preprocessors, and use techniques such as precompiled headers (which essentially means that the preprocessor does some smart caching, so it does not have to read files or expand macro definitions multiple times). With those preprocessors, there is nothing to gain by moving include guards out of the affected headers.

Personally, I would not put include guards outside the affected headers. It is one more thing to be maintained, and the effort to do that exceeds the benefits when many source files include a particular header.

Thanks for the explanations guys. I have never had the opportunity to take a compiler course so I wasn't sure of all the details of this. Hopefully I can take one soon. For fun, if I get bored at work I will run some analysis with Eclipse 3.2 to compare both versions to see how long each takes. I already have some Java that should be able to replace it relatively easy (read: only take an hour to do instead of days by hand). I will be sure to post results when (if) I do it.

Thanks again.

Quote:

---

precompiled headers (which essentially means that the preprocessor does some smart caching, so it does not have to read files or expand macro definitions multiple times).

---

That's not doing the complexity of precompiled headers justice in the least.

What some modern compilers do what really makes this technique unnecessary is this: they recognize the pattern. They know that if the first functional pp tokens in a file are "#ifndef" SYMBOL "#define" SYMBOL and the last token is "#endif", the file is under an include guard. The preprocessor will then put the name of the file into a list.
On every #include, the preprocessor will first look up the file name in the list. If it finds it, it won't bother to even look at the file. "Been there, done that."

Some compilers don't implement this trick, most notably Microsoft's. The MS compiler and compatibles have a different trick: just put
#pragma once
in the header file, and it will be put into a similar list.

Quote:

---

Originally Posted by CornedBee

That's not doing the complexity of precompiled headers justice in the least.

---

I agree CornedBee. I gave one point from the complete story.

Quote:

---

Originally Posted by CornedBee

What some modern compilers do what really makes this technique unnecessary is this: they recognize the pattern. They know that if the first functional pp tokens in a file are "#ifndef" SYMBOL "#define" SYMBOL and the last token is "#endif", the file is under an include guard. The preprocessor will then put the name of the file into a list.
On every #include, the preprocessor will first look up the file name in the list. If it finds it, it won't bother to even look at the file. "Been there, done that."

---

Which is what I vastly over-simplified with one word: "caching".

It's actually the modern preprocessors that do what you describe, not the compiler proper, but yes. I'm saying this in the sense of the phases of compilation described in the standard (preprocessing [logically done by preprocessor] occurs before compilation [logically done by compiler]). The actual implementation with (some) modern compiler products is a bit different: some include the preprocessor and compiler in one executable and, although they do some things in different order, they give the same net effect. (We hope!)

Quote:

---

Originally Posted by CornedBee

Some compilers don't implement this trick, most notably Microsoft's. The MS compiler and compatibles have a different trick: just put
#pragma once
in the header file, and it will be put into a similar list.

---

I actually had mention of #pragma once in a draft of my previous post, but cut it out as an excess level of detail.

The #pragma once was, originally, a workaround for preprocessors that don't do the tricks you described. The catch is, #pragma once is (or "was" in the first Microsoft compilers; I'm not sure offhand if that is still true) done in the compilation phase, and not in the preprocessor phase, affecting execution of lexical analysis done in the compilation phase. It is not a particularly efficient solution to the problem, hence the sort of comment quoted by Loctan.

This technique was recommended, I believe, by Lakos in Large Scale C++ Software Design, and is called "redundant include file guards". The idea is that, even though the include file guard will protect against multiple inclusion. the redundancy will prevent header files from being opened, read, and closed unnecessarily.

It's too bad they didn't design compilers (and the standard) so that all headers were automatically only included once (unless you used some kind of #pragma many statement).

Hm. That wouldn't be good for the code I wrote that had headers designed to be multiply included.

Quote:

---

Originally Posted by Dave_Sinkula

Hm. That wouldn't be good for the code I wrote that had headers designed to be multiply included.

---

But how often is that the case?
Almost every header file I've ever written had header guards.
I'm not even sure what cases would require multiple inclusion of header files?

Quote:

---

I'm not even sure what cases would require multiple inclusion of header files?

---

I cannot think of a good example either; it seems to me that in such cases a macro will suffice.

I found the other way more confusing.
http://cboard.cprogramming.com/showt...539#post186539

Quote:

---

Which is what I vastly over-simplified with one word: "caching".

---

Well, no. The preprocessor doesn't cache anything, really. Rather, it remarks the fact that if it were to include the file again, it would have no effect, so it doesn't. But it doesn't actually store the information of the header for reuse. That's what precompiled headers do.

Quote:

---

It's actually the modern preprocessors that do what you describe, not the compiler proper,

---

I was referring to the compiler whole.

Quote:

---

I'm not even sure what cases would require multiple inclusion of header files?

---

Large tables, enums, etc. are sometimes fed from a header containing calls of an undefined macro. Define the macro the way you need it and include the file, then undefine the macro. Later, define it as something else and include the file again.
The Mozilla source uses this, for example, for the CSS properties.

Quote:

---

Originally Posted by Dave_Sinkula

I found the other way more confusing.
http://cboard.cprogramming.com/showt...539#post186539

---

So in the case where you'd actually want to include multiple times, they could have added a #pragma many statement (the opposite of #pragma once).
That way in 99.999% of header files where you don't want it to be included more than once, you don't have to worry about adding include guards (which is a common noob mistake), and only in the rare cases when you do want it multiply included would you need to add an extra line of code.
But we're stuck with the way it works now, so it doesn't make much difference what I think might have been a good feature...

Quote:

---

Originally Posted by cpjust

So in the case where you'd actually want to include multiple times, they could have added a #pragma many statement (the opposite of #pragma once).

---

I disagree. The bottom line is that the programmer has to understand what will happen when any given input file is fed to the compiler. Introducing #pragma's (which are a standard means of allowing compiler specific extensions) to work around lack of programmer understanding is not a particularly good approach.

The basic issue here is that the preprocessor works by doing text substitution, whereas the C++ (and C) language are token based. The advocates of things like #pragma once tend to incorrectly assume the preprocessing phase honours rules of the language accepted by the compilation phase (hence the fact that such things affect lexical analysis by the compiler).

Quote:

---

Originally Posted by cpjust

That way in 99.999% of header files where you don't want it to be included more than once, you don't have to worry about adding include guards (which is a common noob mistake), and only in the rare cases when you do want it multiply included would you need to add an extra line of code.
But we're stuck with the way it works now, so it doesn't make much difference what I think might have been a good feature...

---

The real solution is either to properly understand the preprocessor (include guards are something quite consistent with how the preprocessor works) or for the language to include some scheme other than the preprocessor for separating declarations from definitions (which happens with a number of languages other than C or C++). Both approaches have their trade-offs, despite each having strong advocates.

Quote:

---

Originally Posted by grumpy

I disagree. The bottom line is that the programmer has to understand what will happen when any given input file is fed to the compiler. Introducing #pragma's (which are a standard means of allowing compiler specific extensions) to work around lack of programmer understanding is not a particularly good approach.

The basic issue here is that the preprocessor works by doing text substitution, whereas the C++ (and C) language are token based. The advocates of things like #pragma once tend to incorrectly assume the preprocessing phase honours rules of the language accepted by the compilation phase (hence the fact that such things affect lexical analysis by the compiler).


The real solution is either to properly understand the preprocessor (include guards are something quite consistent with how the preprocessor works) or for the language to include some scheme other than the preprocessor for separating declarations from definitions (which happens with a number of languages other than C or C++). Both approaches have their trade-offs, despite each having strong advocates.

---

The whole point of compilers is to make programming easier, otherwise we'd all be coding in binary machine code. I've never had a problem with using header guards, but it is more typing, and you need to come up with unique names for the guards...
If the compiler & pre-processor worked the way I described, then understanding how the pre-processor worked would mean understanding that you don't need header guards since it would take care of that automatically and only in the exceptional cases would you need to do something extra.
The goal is to make life easier, not more complicated.