I'm new to programming and the topic of header files is sort of bogging me down after I started using a lot of them. In addition to that I'm trying to use precompiled headers. I'm also using the SFML library so I have those headers that also have to be included.
Right now I have stdafx.h, main.cpp, then classes A, B, C, and D contained within A.h, A.cpp, B.h, B.cpp, C.h, C.cpp, D.h, and D.cpp.
What order would I go about including the headers in all files if
stdafx.h:
#include <SFML/Graphics.hpp>
#include <iostream>
A.h
#include "stdafx.h"
class A
{
//sfml class
};
A.cpp
#include "stdafx.h"
#include "A.h"
B.h
#include "stdafx.h"
class B
{
//sfml class
};
B.cpp
#include "stdafx.h"
#include "B.h"
C.h
#include "B.h"
class C: public B
{
};
C.cpp
#include "stdafx.h"
#include "C.h"
D.h
#include "A.h"
#include "C.h"
class D
{
A a;
C C; // if left uncommented I recieve a '1 unresolved externals' error
//sfml class
}
D.cpp
#include "stdafx.h"
#include "D.h"
main.cpp
#include "stdafx.h"
#include "D.h"
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).
Take a look at a similar question to learn a good approach to authoring headers.
In short, you want to define each header inside a definition guard that prevents headers from being included more then once during compilation. With those in place, for each .h and .cpp file, just include the headers needed to resolve any declarations. The pre-processor and compiler will take care of the rest.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With