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.:
- h file corresponding to this cpp file (if applicable)
- headers from the same component,
- headers from other components,
- system headers.
My rationale for 1. is that it should prove that each header (for which there is a cpp) can be #include
d without prerequisites (terminus technicus: header is "self-contained"). And the rest just seems to flow logically from there.
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 #include
d to be able to use #include "A.h"
in other source files.
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
.
C++ Header order
In a header file you have to include ALL the headers to make it compilable. And don't forget to use forward declarations instead of some headers.
In a source file:
- corresponded header file
- necessary project headers
- 3rd party libraries headers
- standard libraries headers
- system headers
In that order you will not miss any of your header files that forgot to include libraries by their own.
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
.
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.
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.
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 #include
s 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 #include
s 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 #include
s 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).
Related Topics
Blending Does Not Remove Seams in Opencv
May Std::Vector Make Use of Small Buffer Optimization
Opengl - Mouse Coordinates to Space Coordinates
Declaring Multiple Object Pointers on One Line Causes Compiler Error
Forward Declare a Standard Container
What Does '<Cuchar>' Provide, and Where Is It Documented
Explain Morris Inorder Tree Traversal Without Using Stacks or Recursion
How to Properly Use Std::String on Utf-8 in C++
Does the C++ Volatile Keyword Introduce a Memory Fence
In What Ways Do C++ Exceptions Slow Down Code When There Are No Exceptions Thown
How to Create a Pause/Wait Function Using Qt
How to Link to Dynamic Boost Libs
Building a 32-Bit Float Out of Its 4 Composite Bytes
Why Cannot a Non-Member Function Be Used for Overloading the Assignment Operator
"Not Declared in This Scope" Error with Templates and Inheritance
Why Does Ostream_Iterator Not Work as Expected
C++ Memory Model and Race Conditions on Char Arrays
Do I Really Need to Implement User-Provided Constructor for Const Objects