Collecting shared includes in one file - good practice?

I am trying to learn how to deal with a lot of inclusions, and still keep my code in order.

I program a Qt application, and I use files commonly used (and which do not 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/" 

Now I 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 to do this?
  • Does it slow down compilation time?

I also only think of Util.h only in .cpp and have a separate header Header_Util.h . files that look something like this.

Header_Util.h

 #pragma once class IObserver; class QAction; class QDockWidget; class QFileDialog; ... 
  • Is this the best solution?
  • Also, I know that there is something called precompiled headers , but it has never been used. Perhaps this is the solution to my problem and something that I should learn? I use Windows using VS2012 if that matters.
  • ... and summarize all the questions. What would you do in my place?
+6
source share
2 answers

TL DR: As a rule, when developing C ++ or C, it is better to avoid unnecessary visible headers.

Is there a better way to do this?

This is usually a very bad idea when your project is small. Most sources should not see the declaration of most files, but these are high-level objects. At least categorize it.

Does it slow down compilation time?

Generally yes. Example. Do you know most of the source files about the user interface library? Probably not.

Is this the best solution?

Yes. The cost of direct declarations is very low.

Also, I know that there is something called precompiled headers, but it has never been used. Perhaps this is the solution to my problem and something that I should learn?

For some builds, they can save a lot of time. For others, they can only slow down. If you decide to use them, then measure the build time to confirm what is best for your project and includes what you need.

As a rule, you will find that all your sources should not know about something very high and big (for example, in the graphical interface and in the abstraction layer). Only part of the sources usually need to know about these higher-level libraries. This is often a good time to break up your codebase into smaller objects / libraries.

... and summarize all the questions. What would you do in my place?

I would not collect all of these high-level libraries / headers in the header for viewing by all sources. It hurts to undo in large codebases and is usually expensive on the build path. Headings containing forward declarations are good.

+4
source

What you do is generic, although it will be placed in a precompiled header.

A precompiled header (along with precompiled.cpp) is just the header that will be compiled first. Then the obj file from this compilation can be directly included in other headers. This prevents all of your .cpp files from compiling common header files and cpp files over and over. This speeds up compilation time by an order of magnitude.

Setting up a precompiled header is quite simple, and there are enough resources on the Internet for this.

+1
source

Source: https://habr.com/ru/post/943798/


All Articles