C/C++ Include Header File Order

C/C++ include header file order

I don't think there's a recommended order, as long as it compiles! What's annoying is when some headers require other headers to be included first... That's a problem with the headers themselves, not with the order of includes.

My personal preference is to go from local to global, each subsection in alphabetical order, i.e.:

1. h file corresponding to this cpp file (if applicable)
2. headers from the same component,
3. headers from other components,
4. system headers.

My rationale for 1. is that it should prove that each header (for which there is a cpp) can be #included without prerequisites (terminus technicus: header is "self-contained"). And the rest just seems to flow logically from there.

C++ Header & Source Files - What To Include And In Which Order

Which file do I need to include where

#include directive in fact is very simple preprocessor directive, which just adds content of the specified file into the target file. Conventionally you keep declaration of functions in a header file and definition of the said functions in the corresponding cpp file, and thus you at least want to have the header included there (in your case A.cpp includes A.h and B.cpp includes B.h). Additionally you include headers in any file where you use the functions declared in the headers (e.g. if you use declarations of A.h and B.h in Main.cpp you include those files as well).

P.S. You, however, can define everything right in the header file, next to declarations, but as I said earlier preprocessor doesn't do anything fancy - it just adds the content of the include in the target file, and you usually don't want to have all definitions in place, because each translation unit which has it included will have the same definitions repeated over and over again.

Ordering of C++ #include's

In dir2.h, you forget to include X.h. Then in current file you include:

X.h
dir2.h

This will compile fine. Then someone else includes dir2.h somewhere else and they end up with compilation error originating from dir2.h, even if they never changed anything in that file...

If you have the correct order, you should get the error first time you include dir2.h.

what's the right order between system header and user header file in C/C++ source?

When it comes to header files, I have used the first approach exclusively as long as I can remember.

When it comes to source files, I use the same approach unless there is a header file that corresponds to a source file. In the case, I #include the particular header file first.

Let's say I have A.h that declares a class or some functions and A.cc implements them. In that case, I use:

A.c:

#include "A.h"

// Standard includes

// User includes

This is useful in weeding out any missing forward declarations or standard include files that are necessary to make A.h a reusable header file without worrying about what else must be #included to be able to use #include "A.h" in other source files.

What order do I include header files in?

My philosophy is that in well-written code, header files should include all other header files that they depend on. My reasoning is that it should not be possible to include a header file and get a compiler error for doing so. Therefore, each header file should (after the #ifdef or #pragma once include guard) include all other headers it depends on.

In order to informally test that you've remembered to include the right headers in your header files, *.cpp files should #include the minimum set of header files that should work. Therefore, if there are separate header files for A, B, C and D, and your cpp file uses class D, then it should only include D.h. No compiler errors should result, because D.h #includes A.h and C.h, C.h includes B.h, and A.h and B.h include the SFML header (whatever that is). C.h and D.h can include the SFML header if it seems appropriate, but it's not really necessary, if you can be sure that the dependencies (B.h and A.h) already included it.

The way Visual C++ does "precompiled headers" screws up this logic, however. It requires you to include "StdAfx.h" as the very first header file, which causes many developers to simply put all #includes for the entire project in StdAfx.h, and not to use #include in any of the other header files. I don't recommend this. Or, they will put all external dependencies in StdAfx.h (e.g. windows.h, boost headers) and #include the local dependencies elsewhere so that changing a single header file does not necessarily cause the entire project to rebuild.

The way I write my code, most of my CPP files include StdAfx.h, and the corresponding .H file. So A.cpp includes StdAfx.h and A.h, B.cpp includes StdAfx.h and B.h, and so forth. The only other #includes placed in a cpp file are "internal" dependencies that are not exposed by the header file. For example, if class A calls printf(), then A.cpp (not A.h) would #include <stdio.h>, because A.h does not depend on stdio.h.

If you follow these rules then the order that you #include headers does not matter (unless you use precompiled headers: then the precompiled header comes first in each cpp file, but does not need to be included from header files).

Google C++ Style Guide include order

Every header file(h, hpp,...) should have an implementation file (cpp, cc,...) where the order of including is the same as specified in the question. (Even if the implentation file is empty, except for this 1 include)

So just like "Your" header is included first in "Your" implementation file, so every "other" header file should be included first in the "other" implementation file.

This way if the "other" header does not include a required header, the "other" implementation file will not compile.

Header file order

Headers should be written to, as much as possible, 1) be independent of what may have already be included, and 2) not introduce problems (such as macros for common identifiers) for headers later included. When both of these are true, the order in which you include doesn't matter. If these aren't true, you should fix that in your own headers, or deal with it as necessary otherwise.

Thus, the choice is arbitrary, but it is still important that you make a choice! "The plan is nothing, but the planning is everything." Consistency leads to more readable code.

A relatively common order is standard library, system (as in OS), external libraries, and then headers for the same project as the current file – with the one exception of an implementation file including its "corresponding" header (if there is one) first, before any includes or other code. Within each group, I sort alphabetically by habit, because, again, it's completely arbitrary but some easy to use order lets me quickly read and update the list.

Applied to your list:

// first only because this is required in your precompiled header setup
#include "stdafx.h"

// it's too bad this can't really be first
// I'm guessing "This" refers to the corresponding header
#include "This.h"

// C stdlib then C++ stdlib is what I usually do,
// whether the C headers are spelled XXX.h or cXXX.
#include <math.h>
#include <stdio.h>
#include <iostream>
#include <list>
#include <string>

// someone mentioned winsock2 needs to be before windows
#include <Winsock2.h>

#include <tchar.h>
#include <Windows.h>

#include <boost/regex.hpp>

#include "mystring_written_by_c.h"
#include "mystring_written_by_cpp.h"

The line breaks above to split into groups are deliberate. I would leave a comment on why winsock2 is given its own group, but the rest of the comments would not normally be there.

Why does the order of my #includes matter? (C++)

Generally speaking it should not, however it may be possible for there to be conflicting definitions of symbols or preprocessor macros that end up confusing the compiler. Try to narrow down the size of the problem by removing pieces and includes from the conflicting header until you can see what is causing it.

In response to the error messages you posted, the symbol NULL is often implemented as a preprocessor macro for the number 0. This is so that you can easily use it as a null pointer. Therefore this:

list(const T& NULL);

Could be converted into this syntax error by the preprocessor:

list(const T& 0);

Change the name of the parameter to something other than NULL.

---

Related Topics