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?
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.
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.
Related
I have been placing my #include statements in the header file, then only including the header in main to make my main file look cleaner. However, every other C++ code I look at leaves them in main. Does it make a difference either way? If it does, why?
Example:
Header:
#pragma once
#include <iostream>
#include <string>
#include <iomanip>
#include <fstream>
using namespace std;
class Question
{
private:
Main:
#include "Header.h"
int main()
{
There are a few considerations:
you want to minimize header inclusions because they slow down the builds, and increase the dependency tree. Code that includes your header depends on every header it includes, and every header that they include, and so on, all the way down. Suppose a some user includes your header, and you include 20 other headers in it, then
any time any of those headers you include changes, the client code has to recompile
client code has to parse all those headers every time it builds.
The real problem is the multiplying effect: you get slower builds that also have to be done more often (because the number of files depended on goes up.) This is partly why c++ projects are so slow to build. Some headers contain substantial amounts of complex template code, and it gets compiled over and over, for each translation unit that it appears.
The fewer inclusions your headers have, the less implementation detail you depend on as well. The attitude of "put lots of code into headers!" tends to make them contain more implementation detail than necessary. That is, instead of merely declaring a function, it also defines the function, then that means development work happens in the header, not the cpp file. So that makes the headers change even more often, causing everyone who includes it to need to be rebuilt for (oftentimes) no good reason.
When you keep an include isolated inside a .cpp file, then only that cpp file has the dependency on it--not your users. This helps isolate your clients from having to parse and build the headers that you use but don't need to provide.
More things included in headers also causes more names to be visible to consumer code. This can increase name collisions, create ambiguities, possibly have macros interfere, and so on. Namespaces can help, but if a user gets 100 overloads of operator<< because they include your header, then every time they need to resolve an overloaded <<, the compiler has 100x more functions to choose from to decide which one to call, which again can slow down the build. And so on.
The goal is to minimize what you expose to your users, and the header is what you expose.
Only put the minimum required #include in a .h file. That way you prevent unexpected code collisions and unnecessary make dependencies.
It only makes a difference for bigger projects. If you include a lot of headers in headers and have a lot of source files you will include headers multiple times. This can drastically increase compile times.
For small projects (~10000 lines) it is fine either way.
I've been learning more about headers, translation units, and precompiled headers lately. I think I understand them well now. I do have a couple queries though, I'll just ask one here. This is just a theoretical example so it may or may not work in practice, but please try to understand what I'm asking.
Say I have a precompiled header like so:
// stdafx.h
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
and some source file.
// foo.cpp
#include "stdafx.h"
#include <Windows.h>
void bar()
{
// I need to access something in Windows.h that requires
// WIN32_LEAN_AND_MEAN to NOT be defined.
}
It doesn't have to be precompiled headers, but any similar structure in general, though I'm not sure it'd apply otherwise. I can work around this problem with Windows.h easily enough, but I'm sure there are much more difficult situations.
Is it possible in anyway to remove the currently included Windows.h from the precompiled header and reinclude it with adjusted #defines. #undef won't work to my understanding.
The only solution that comes to mind is to create a separate source file and mark it as not using precompiled headers. I'd like to learn of any alternatives.
Also, what would be a more general way to express what I'm asking for the sake of future endeavors and search engine results?
I know in C++ you have to use the "#include" statement to include libraries and headers, like:
#include <iostream>
#include <string>
#include "my_header.h"
But after some time, that can look very ugly, having a load of includes in your files. I wanted to know if there is some way where we can call just 1 file to include EVERYTHING we'll need in the C++ project. Kind of like...
"include_everything.h"
#include <iostream>
#include <string>
#include "header1.h"
#include "header2.h"
and then in our .cpp file, could we go?
#include "include_everything.h"
// write code here...
If it is possible, is it lawful? Does it abide by the C++ coding laws?
Thanks in advance,
Gumptastic
If that is the only rule you decide not to follow you will probably be fine. But, depending on what some of those headers contain (macros, #defines, etc) you could get a horrible mess in the end.
I've seen cases where people included what they thought they needed (often ended up being much more than was needed as they failed to consider forward declarations). On a large software project, each CPP file ended up loading nearly every include file anyway (due to chaining). Often the same file would get loaded multiple time and only excluded once the #ifndef statement at the top was triggered. The OS ended up opening over 100k files for each compile even though only there were only 50k files in the project. In a horrible situation like that it might help.
It can save time for developers as they, generally, won't have to search out where something is defined and add it to their include list for every file they work on. Do it once and forget. Let the compiler tell you if a new file needs to be added to 'everything'.
Aside from the macro problem you might run into issues with overlapping names and such if you don't properly use namespaces. Also, template classes often have real code in the header file. This can create churn.
It might also cause problems if people are using global variables and they are eclipsing local variables. It might be hard to figure out where that global 'i' is defined and being pulled in from if you have to search all files in 'everything' instead of just the files in your include list.
You can do it. If its just you and includes bug you, go for it. If you are your buds are doing something, sure. You are going to serious looks from people if you try to do this on a medium sized project or larger.
At best, I wouldn't suggest using to go beyond grouping tightly bundled headers together into a more coherent API.
You can do this, but it might affect compilation time.
The C(++) #include compiler instruction means nothing more than "Before you compile, copy and paste the content of that file here". That means when you include more headers than necessary, it will take a bit longer to compile each source file. But when that's not a concern for you, go ahead.
Yes, you can do it. You may recursively include headers.
However, If you are including so many headers that this is a problem, either you're including ithings you don't need to include or your source files are way too expansive.
Consequently, it's very rare to do this and I'd go so far as to consider it a big code smell. The only time you really want to do it is when you're going to precompile that include_everything.h.
Sometimes in C++ the order of the includes matters. That is the case of openGL using :
1.- Right way:
#include <windows.h> // Header File For Windows
#include <gl\glu.h> // Header File For The GLu32 Library
2.- Wrong way:
#include <gl\glu.h> // Header File For The GLu32 Library
#include <windows.h> // Header File For Windows
Does this happen just for some specific headers or is it kind of a
random problem difficult to prevent a priori?
If that is the case:
How can I know the right order of the includes?
Just some specific headers. Some might call it a design flaw.
You can't. Look at the error messages you get and sort them out carefully. On windows, putting windows.h first is probably a good idea.
The order does not matter for C++ Standard Library includes.
For other libraries it should not usually matter (unless they specifically say so).
For specific platforms, it may matter and it is usually specified clearly when it does.
For ex:
On Windows #include <windows.h> comes before all the other includes.
Also,
#include <stdafx.h>
which is a MSVC++ specific header needs to be included before everything else if you're using precompiled headers.
For windows you need the #include <windows.h> first.
Then in the header files avoid #include - prefer forward declarations instead.
Save less compilation when you just change one header file.
At one time, a fair number of well-known C programmers advised that no header should include any other header -- it should be up to the user to include the correct headers in the correct order to make things work. This worked (and continues to work) pretty well for small projects that don't involve too many headers.
For larger projects, however, keeping track of all the header dependencies can/does become substantially more difficult, to the point that it's nearly unmanageable in many modern code bases. Most modern headers themselves include any other headers upon which they depend.
Unfortunately, that means we frequently end up with a rather confusing mixture of the two. There's not much you can do beyond just dealing with it when it arises, by finding what headers you need to include and in what order.
I have been making several games with the Allegro API and C++. I have also been putting all my classes in 1 big main.cpp file. I tried many times to make .h and .cpp files, but my big problem is I have trouble with #including at the right place. For example, I want all my classes to access the allegro library without #including allegro.h everywhere. Could someone please explain how to correctly #include things. In .Net, everything seems to come together, but in c++ one thing cannot be used before it is included. Is there also a way to globally include something throughout my entire program?
Thanks
I want all my classes to access the allegro library without #including allegro.h everywhere.
Why? That is how you do it in C++ land.
Could someone please explain how to correctly #include things. In .Net, everything seems to come together, but in c++ one thing cannot be used before it is included
Conceptually, in .NET, it is not much different at all. You still have to place "using " at the top. The difference there is that, in .NET, you could also write this every time if you wanted to:
void Foo( System.Drawing.Drawing2D.BitmapData bData ) { }
A common way to do this is to have a master include file that includes all of the others in the correct order. This works especially well if you use precompiled headers so
in precomp.h
#include <stdio.h>
#include <allegro.h>
.. etc.
in myfile.cpp
#include "precomp.h"
in myfile2.cpp
#include "precomp.h"
and so on.