Is it a good practice to merge include directives in one file

Question

I think that all is in the title.

Say we have a project with this structure:

+ src
    main.cpp
    task1.cpp
    task2.cpp
+ includes
    main.h
    task1.h
    task2.h

both task1.h and task2.h uses <QPushButton> and <QLabel>.

is it a good idea to create an other header file ( core.h ) and put this includes into

// core.h
#include <QPushButton>
#include <QLabel>

and then call it from each task1.h and task2.h files.

is there any changes that can be noticed when doing it this way ( compilation time, programming restrictions, ... )

Answer 1

You would only do this if you were using "precompiled headers". Otherwise it doesn't make much sense.

• Use forward declarations where possible.
• Add includes in the files where you need a full declaration of a type.

Using a header file where you put all include files makes impossible for the build system to track the dependencies of changed files. Suddenly all your code depends on your core.h header. If this header is changed, all your code has to be recompiled, even there is no actual change.

Answer 2

IMO core headers are good practice:

• for small projects;
• if you restrict them to containing things that seldom change.

A core.h doesn't scale well to medium- or large-sized projects. There are several problems with this approach:

• it is difficult to analyze or manage dependencies when everything is dependent upon everything in this one file;
• whenever anything in that one header changes, everything will be recompiled;
• instead of thinking about where things really belong, programmers just keep dumping things into this one file;
• the namespace for every compilation unit is polluted with everything that is in that one file.