Collect common includes in a single file - good practice?

Question

I am trying to learn how to deal with a lot of includes, and still keep my code tidy.

I am programming a Qt application and I have put files commonly used (and that doesn't change) in a file called "Util.h".

Util.h

#pragma once

#include <Core/IObserver.h>
#include <Core/Math.h>
#include <QAction>
#include <QDockWidget.h>
#include <QFileDialog>
#include <QGraphicsBlurEffect>
#include <QLabel.h>
#include <QMainWindow.h>
#include <QMenu.h>
#include <QMessageBox.h>
#include <QShortcut.h>
#include <QSignalMapper>
#include <QSound>
#include <QString>
#include <QTimer.h>
#include <QTreeView>
#include <QStandardItemModel>


// Path to icons
#define ICON_PATH                                               \
    "../../Assets/GUI/Icons/"

This I then include it in almost all of my header files

#include "Util.h"
#include "Manager_Docks.h"
#include "Manager_Tools.h"
#include "Manager_Console.h"
#include "ui_MainWindow.h"
...

• Is there a better way of doing it?
• Does this slow down compile time much?

I'm also thinking of only including Util.h in every .cpp only, and have a separate Header_Util.h for header files, looking something like this

Header_Util.h

#pragma once

class IObserver;
class QAction;
class QDockWidget;
class QFileDialog;
...

• Is this a better solution?
• Also, I am aware that there is something called precompiled headers, but have never used myself. Is this perhaps a solution to my problem and something I should look into? I'm on Windows using VS2012 if that makes any difference.
• ...and to summarize all questions. What would you have done in my place?

Answer 1

TL;DR: Generally, it's best to eliminate unnecessarily visible headers when developing C++ or C.

Is there a better way of doing it?

It's generally a very bad idea when your project is not small. Most sources won't need to see the declaration of most files, and those are high level objects. At least divide it by category.

Does this slow down compile time much?

Generally, yes. Example: Do most of your source files need to know about the UI library? Probably not.

Is this a better solution?

Yes. The forward declarations' cost is very very small.

Also, I am aware that there is something called precompiled headers, but have never used myself. Is this perhaps a solution to my problem and something I should look into?

For some builds, they can save a lot of time. For others, they may only slow things down. If you choose to use them, then measure the build times to confirm which is better for your project and the includes you need.

Typically, you find all your sources don't need to know about something very high level and large (e.g. a GUI library and abstraction layer). Only a portion of the sources generally need to know about those higher level libraries. This is often a good point to break up your codebase into smaller targets/libraries.

...and to summarize all questions. What would you have done in my place?

I wouldn't stuff all those high level libraries/headers in a header for all sources to see. It's painful to undo in large codebases and tends to cost a lot in build times along the way. Headers containing forward declarations are good.

Answer 2

What you're doing is common, although it would be placed within a precompiled header.

A precompiled header (along with a precompiled.cpp) is just a header that will be compile first. The obj file from this compilation can then be directly included into other headers. This prevents all your .cpp files from compiling common header files and cpp files over and over and over again. This speeds up compile times by orders of magnitude.

Setting up a precompiled header is quite simple, and there are quite a few resources online for doing such.