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.
Related
The question is about including an unnecessary header to avoid calling it multiple times in sub-files.
Here's the scenario, I have a few files:
srlogger.h
srinterface.h
srinterface.cc
#include <srinterface.h>
#include "srlogger.h"
srbinhttp.h
#include "srinterface.h"
srbinhttp.cc
#include <srbinhttp.h>
#include "srlogger.h"
srsocket.h
#include "srinterface.h"
srsocket.cc
#include <srsocket.h>
#include "srlogger.h"
srhttp.h
#include "srinterface.h"
srhttp.cc
#include <srhttp.h>
#include "srlogger.h"
Now, what I want to do is to remove the #include "srlogger.h" from all .cc files shown, and instead include it to the srinterface.h file as:
srinterface.h
#include "srlogger.h"
Since all of the .cc respective header files include the srinterface.h the srlogger.h would be covered.
Now, why would this be bad?
Please do not say that you should only include the necessary headers to compile and nothing extra, this is not enough explanation.
I want to know in real examples why this would be bad.
Oh if someone removes the #include "srlogger.h" from the srinterface.h it would break the other file, this is a weak explanation. A comment after the include could easily warn other people.
What interests me the most is if it will affect the compilation in a bad way, will the size of the objects or executable files change because of that, does it affect performance.
Or you have a really good explanation why this is bad.
PS.: If you are curious why would I want to do that, is because I was mapping the dependencies between the files, and doing such a thing I can create a graphical visualization between all the dependencies, making it easier to understand how the pieces of the puzzle fit together. Transferring sub-headers to common header in the higher hierarchy header creates a more organized structure between the all files.
The potential negative effect is one of compile time. If someone includes your header who doesn't need the header it drags in, the compile time of that compilation unit will increase for no good reason.
For toy projects or small projects (of a few hundred files) that compile in a few seconds, this makes no real difference.
But when you work on projects that are millions of lines of code spread across hundreds of thousands of files, that already take a significant fraction of an hour to compile, and you add an include to a header that's included by 12000 other files because you could not be bothered to explicitly add it to the 120 files that actually needed it (but just happened to include the common header) - then you are not going to be popular, since you just increased everyones average build time by several minutes.
There is also the risk (in bad code bases) that the header you (unnessesarily) drag in to other files may redefine stuff that breaks things for that source file that didn't even need the other header in the first place.
For the above reasons, I believe that headers should only include what they really need themselves and cannot forward declare. Implementation files should only include headers they really need (and include their own headers first to make sure they are self contained).
Hope that answers your question.
"The question is about including an unnecessary header to avoid calling it multiple times in sub-files."
Include guards will solve the feasible part of this problem of including multiple headers in the same file. Include guards will cut down the unnecessary includes to a certain extent. See the link below:
C++ #include guards
An include guard is made by adding the following to your header file:
//at the very top of the header
#ifndef NAMEOFHEADER_H
#define NAMEOFHEADER_H
// header info
//at the very last line of the header
#endif
This will keep you from accumulating the same header file multiple times in another .h or .cpp file.
And as was stated in the comment below, even if every header has include guards you can still end up with information not even needed for your file being defined by the compiler during its preprocessor directives. This is bound to happen with the chain of includes across multiple files.
Lets say I want to use hex() function. I know it is defined in <ios> header and I also know that it is included in <iostream> header. The difference is that in <iostream> are much more functions and other stuff I don't need.
From a performance stand-point, should I care about including/defining less functions, classes etc. than more?
There is no run time performance hit.
However, there could be excessive compile time hit if tons of unnecessary headers are included.
Also, when this is done, you can create unnecessary recompiles if, for instance, a header is changed but a file that doesn't use it includes it.
In small projects (with small headers included), this doesn't matter. As a project grows, it may.
If the standard says it is defined in header <ios> then include header <ios> because you can't guarantee it will be included in/through any other header.
TL;DR: In general, it is better to only include what you need. Including more can have an adverse effect on binary size and startup (should be insignificant), but mostly hurts compilation-time without precompiled headers.
Well, naturally you have to include at least those headers together guaranteed to cover all your uses.
It might sometimes happen to "work" anyway, because the standard C++ headers are all allowed to include each other as the implementer wants, and the headers are allowed to include additional symbols in the std-namespace anyway (see Why is "using namespace std" considered bad practice?).
Next, sometimes including an additional header might lead to creation of additional objects (see std::ios_base::Init), though a well-designed library minimizes such (that is the only instance in the standard library, as far as I know).
But the big issue isn't actually size and efficiency of the compiled (and optimized) binary (which should be unaffected, aside from the previous point, whose effect should be miniscule), but compilation-time while actively developing (see also How does #include <bits/stdc++.h> work in C++?).
And the latter is (severely, so much that the comittee is working on a modules-proposal, see C++ Modules - why were they removed from C++0x? Will they be back later on?) adversely affected by adding superfluous headers.
Unless, naturally, you are using precompiled-headers (see Why use Precompiled Headers (C/C++)?), in which case including more in the precompiled headers and thus everywhere instead of only where needed, as long as those headers are not modified, will actually reduce compile-times most of the time.
There is a clang-based tool for finding out the minimum headers, called include-what-you-use.
It analyzes the clang AST to decide that, which is both a strength and a weakness:
You don't need to teach it about all the symbols a header makes available, but it also doesn't know whether things just worked out that way in that revision, or whether they are contractual.
So you need to double-check its results.
Including unnecessary headers has following downsides.
Longer compile time, linker has to remove all the unused symbols.
If you have added extra headers in CPP, it will only affect your code.
But if you are distributing your code as a library and you have added unnecessary headers in your header files. Client code will be burdened with locating the headers that you have used.
Do not trust indirect inclusion, use the header in which required function is actually defined.
Also in a project as a good programming practice headers should be included in order of reducing dependency.
//local header -- most dependent on other headers
#include <project/impl.hpp>
//Third party library headers -- moderately dependent on other headers
#include <boost/optional.hpp>
//standard C++ header -- least dependent on other header
#include <string>
And things that won't be affected is run-time, linker will get rid of unused symbols during compilation.
Including unneeded header files has some value.
It does take less coding effort to include a cut and paste of the usually needed includes. Of course, later coding is now encumbered with not knowing what was truly needed.
Especially in C, with its limited name space control, including unneeded headers promptly detects collisions. Say code defined a global non-static variable or function that happened to match the standard, like erfc() to do some text processing. By including <math.h>, the collision is detected with double erfc(double x), even though this .c file does no FP math yet other .c files do.
#include <math.h>
char *erfc(char *a, char *b);
OTOH, had this .c file not included <math.h>, at link time, the collision would be detected. The impact of this delayed notice could be great if the code base for years did not need FP math and now does, only to detect char *erfc(char *a, char *b) used in many places.
IMO: Make a reasonable effort to not include unneeded header files, but do not worry about including a few extra, especially if they are common ones. If an automated method exist, use it to control header file inclusion.
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.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
where should “include” be put in C++
Obviously, there are two "schools of thought" as to whether to put #include directives into C++ header files (or, as an alternative, put #include only into cpp files). Some people say it's ok, others say it only causes problems. Does anybody know whether this discussion has reached a conclusion what is to be preferred?
I am not aware of any schools of thoughts concerning this. Put them in the header when they are needed there, otherwise forward declare and put them in the .cpp files that require them. There is no benefit in including headers where they are not needed.
What I found effective is following a few simple rules:
Headers shall be self-sufficient, i.e., they shall declare classes they need names for and include headers for any definition they use.
Headers should minimize dependencies as much as possible without violation the previous point.
Getting the first point rught is fairly easy: Include the header first thing from the source implementing what it declares. Getting the second point exactly right isn't trivial, though, and I think it requires tool support to get it exactly right. However, a few unnecessary dependencies generally aren't that bad.
As a rule of thumb, you don't include the headers in a header as long as full definition of them is necessary there. Most of the time you play around with pointers of classes in a header file so it's just fine to forward declare them there.
I think the issue was settle a long time ago: headers should be self-contained (that is should not depend on the user to have included other headers before -- that aspect is settle for so long that some aren't even aware there was a debate on this, but your put includes only in .cpp seems to hint at this) but minimal (i.e. should not include definitions when a declaration would be enough for self-containment).
The reason for self-containment is maintenance: should an header be modified and now depend on something new, you'd have to track all the place it is used to include the new dependency. BTW, the standard trick to ensure self-containment is to include the header providing the declarations for things defined in a .cpp first in the .cpp.
These are not schools of thought so much as religions. In reality, both approaches have their advantages and disadvantages, and there are certain practices to be followed for either approach to be successful. But only one of these approaches will "scale" to large projects.
The advantage of not including headers inside headers is faster compilation. However, this advantage does not come from headers being read only once, because even if you include headers inside headers, smart compilers can work that out. The speed advantage comes from the fact that you include only those headers which are strictly necessary for a given source file. Another advantage is that if we look at a source file, we can see exactly what its dependencies are: the flat list of header files gives that to us plainly.
However, this practice is hard to maintain, especially in large projects with many programmers. It's quite an inconvenience when you want to use module foo, but you cannot just #include "foo.h": you need to include 35 other headers.
What ends up happening is this: programmers are not going to waste their time discovering the exact, minimal set of headers that they need just to add module foo. To save time, they will go to some example source file similar to the one they are working on, and cut and paste all of the #include directives. Then they will try compiling it, and if it doesn't build, then they will cut and paste more #include directives from yet elsewhere, and repeat that until it works.
The net result is that, little by little, you lose the advantage of faster compiling, because your files are now including unnecessary headers. Moreover, the list of #include directives no longer shows the true dependencies. Moreover, when you do incremental compiles now, you compile more than is necessary due to these false dependencies.
Once every source file includes nearly every header, you might as well have a big everything.h which includes all the headers, and then #include "everything.h" in every source file.
So this practice of including just specific headers is best left to small projects that are carefully maintained by a handful of developers who have plenty of time to maintain the ethic of minimal include dependencies by hand, or write tools to hunt down unnecessary #include directives.
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.