3

I was revisiting my question How can I prevent header hell?, when I noticed a comment which said

A good technique for ensuring a header is independent is having a rule that the source file always includes its own header first. This will catch cases where you need to move dependency includes out of the implementation file into the header file

I am not sure that I follow that, and the reverse seems to have been the rule everywhere that I have worked. I never thought about it, or questioned it.

Are there any technical reasons for a .C or .CPP file to #include its own header file either for or last, or does it make no difference?

I am looking for technical reasons, not opinions. Nothing with “best”, which would be opinion. Answers which might help to prevent problems when refactoring or adding/removing other #includes are welcome.

5

#include directives are processed in the order in which they are encountered in the sources. Conceptually, when a #include is encountered, that directive is replaced with the content of the referenced file and after that processing continues with the modified source (so, processing continues on the first line that came from the included file).

If the very first #include directive in a source file is for the header that corresponds to that source file, then you can be sure that no other headers have been processed yet and you can prove that your header does not depend on some other header being included before it.

Other than that, it does not make any difference at all to the C or C++ compiler in which order header files are listed, as long as the constraint is met that every identifier is declared before it is used.

  • 1
    "you can prove that your header does not depend on some other header being included before it". But, generally, it does, which his why I insist that every file, including header files, can be compiled stand-alone. If that rule is followed then of course you are correct to say “it does not make any difference at all to the C or C++ compiler in which order header files are listed” ... -> – Mawg Nov 27 '18 at 10:23
  • Which is why I ask this question, trying to understand that comment to my previous question. I wonder if that comment can be technically justified; if so, it is not on complication grounds, but there may possibly be other reasons. Possibly some "safer that way if you do X" reasons? Or speeding up compilation times? Any ideas? – Mawg Nov 27 '18 at 10:24
  • 1
    @Mawg: The rule to put the own header first is an alternative to the rule that every header file must be able to compile stand-alone. The only effective difference is when a compiler refuses to compile header files on their own. – Bart van Ingen Schenau Nov 27 '18 at 11:22
2

There are two options for header structure I have seen used:

  1. Headers do not include headers. This approach has the advantage that headers are light, and you don't get lots of needless multi-inclusion slowing things down. It's bad because it's tricky to use and unstable under modification. I need to find out every include needed by a header file in order to include it and if, at any time, the header needs a new include then I will have to modify every file that includes it.

  2. Headers include everything they need to compile. This method means that I can always include just the header I want and it will work. Including the header first is simply a way of ensuring this contract is met. Because there is nothing included before the first include in the source file, the inclusion guarantees that the header will compile independently of other headers. The downside is a small cost in compilation time (which modern compilers cope with quite well) and although this approach is stable for adding additional includes, removing includes from a header file can cause files that include that header to fail to compile.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.