#include's in .h or .cpp files

Question

I'm currently creating a project that utilized a lot of forward declarations and such so I've come across an issue where my #includes seem to be extremely redundant.

Example:

config.h

#include <Windows.h>
#include <vector>

config.cpp

#include "config.h"
#include "resolve.h"
#include <Windows.h>
#include <vector>
//functions that use extern functions/variables.

resolve.cpp

#include "config.h"
#include "resolve.h"
#include <iostream>
#include <Windows.h>
#include <winternl.h>
#include <TlHelp32.h>
//functions that use extern functions/variables.

main.cpp

#include "config.h"
#include "resolve.h"
#include <iostream>
//functions that use extern functions/variables.

Would it be better for me to do something like flow them so there aren't any duplicate #includes for something like this?

config.h

#include <vector>
#include <iostream>
#include <Windows.h>
#include <winternl.h>
#include <TlHelp32.h>
//declarations for config.cpp

resolve.h

#include "config.h"
//declarations for resolve.cpp

config.cpp

#include "resolve.h"

resolve.cpp

#include "resolve.h"

main.cpp

#include "resolve.h"

So this way everything already has the headers they need + the forward declarations?

Answer 1

Normal best practice is for every file to include all the header files it requires, disregarding #include directives in included files. Each header file should then have a construct like this so that it's contents are only included once:

#ifndef _HEADER_FILE_NAME_H
#define _HEADER_FILE_NAME_H

.... header file contents

#endif

This takes care of redundancy by insuring the contents are only included once, the first time the file is included. Subsequent inclusions will skip the contents because the guard symbol was defined during the first inclusion.

Answer 2

Once you have adopted #include guards or #pragma once as proposed by Todd Knarr in the other answer, redundant includes are technically no longer an issue.

However, your question would still remain: should the headers be included explicitly everywhere they are potentially needed ? Or should they be nested one in another, like matriochka dolls, in order to reduce the number of includes ?

Make headers self sufficient

If you need a resolver, just include resolve.h. You shouldn't have to worry what other headers you would need for it to work.

So if the declaration in resolve.h would depend somehow on config.h, include it in the first header. The huge advantage, is that if you'd one day refactor the resolver, and get rid of its dependency to config.h, or if on contrary you'd add a new dependency to resolve_base.h, you'd just change this in one header : a very good example of separation of concerns.

Reinforce encapsulation and keep coupling to its minimum

It is possible that resolve.cpp needs additional includes, for example windows.h or iostream because the implementation depends on other compilation units. If these includes are not required by resolve.h they are an implemetnation detail: don't created unnecessary couplings; don't include them there: the users of resolve.h don't need to know these dependencies. Include them only in resolve.cpp. This gives you flexibility to change the implementation, without having to propagate changes that should not affect other modules.

Convenience and speed

There are some includes that you use in many many compilation units. It could then be a pragmatic approach to include these in a common header that you would then include in all the implementation files:

• less explicit dependencies
• but a lot of typing less (and avoidance of error message caused by forgotten headers).

This can be further justified if your compiler uses pre-compiled headers (e.g. stdafx.h with MSVC).

Aditional reading

• C++ Best practices - designing header files
• Google C++ style guide
• C++ core guidelines