Include own header file first or last? Any technical reasons?

Question

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.

Answer 1

#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.

Answer 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.