3

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.

sepp2k
  • 363,768
  • 54
  • 674
  • 675
Daniel
  • 33
  • 3
  • 1
    This doesn't address the question, but use `#include <...>` for system headers and `#include "..."` for your own headers. – Pete Becker Aug 09 '17 at 21:39
  • @Pete Becker - I don't disagree, but you should explain *why*. Also, if you tell your compiler about your own include dirs then using "<>" can be just fine.. In any case; your comment doesn't explain the *difference* between the two forms, but just says "do this" which is not really as helpful as it could be. – Jesper Juhl Aug 09 '17 at 21:48
  • 1
    @JesperJuhl -- I would agree if that had been an answer. But it's not, and since it isn't intended to address the question, it's short, and not intended to start a discussion. – Pete Becker Aug 09 '17 at 21:49
  • @Pete Becker - fair enough. I can accept that :-) – Jesper Juhl Aug 09 '17 at 21:53

2 Answers2

3

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.

Jesper Juhl
  • 30,449
  • 3
  • 47
  • 70
  • 1
    I can see your point, it makes sense, thanks. I also did some more research on it, I guess the object files and the program would increase because of it. I found this video useful showing the compilation and linkage, gotta skip to the middle though: https://www.youtube.com/watch?v=5UMHbzZGQuE&index=17&list=PLggLP4f-rq02gmlePH-vQJ8PF6hyf08CN – Daniel Aug 10 '17 at 11:30
1

"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.

9Breaker
  • 724
  • 6
  • 16
  • 1
    Include guards don't help you when the header is included in 10000 files but the extra include you added to the header was only needed by 10. All 10000 source files now need to pay the cost of compiling that extra header (and that adds up to real time - minutes) quickly - for big code bases). – Jesper Juhl Aug 09 '17 at 21:30