-3

If a file foo.cpp already includes foo.h, and foo.cpp requires some types from (for example, string.h), which is better, to include string.h in foo.cpp, or in foo.h ?

For example, Guideline#9 in this tutorial recommends to include it in the cpp, if possible, but I don't understand exactly why.

12
  • 1
    Hello Ahmed, askers on this site are expected to do some research first on their own, show us what they found and why it did not suit their needs. A start, for example, could be to tell us is where you got the impression from that the kind of includes you mentioned are "bad". In the current form, expect your question to be closed as "unclear" or "primarily opinion based", since it contains hardly enough information to give you a sensible answer.
    – Doc Brown
    Commented Jan 1, 2019 at 12:09
  • Thanks Doc.They are bad according to something like Guideline#9 in this tutorial: umich.edu/~eecs381/handouts/CppHeaderFileGuidelines.pdf
    – Ahmed Adel
    Commented Jan 1, 2019 at 12:23
  • 1
    That’s not what guideline 9 says... it says not to include header files needed by the .cpp file if they are not needed by the .h file. Commented Jan 1, 2019 at 12:36
  • @AhmedAdel: #9 says clearly, if string is required in A.h (because, for example, A.h contains a class definition with a string member), string should be included. So maybe you just misunderstood something?
    – Doc Brown
    Commented Jan 1, 2019 at 13:00
  • 1
    in general, only include a header file in a file (which might be another header file) when the contents of the included header file are needed. Doing otherwise result in 'over' coupled code and too many recompiles needed when the original header file is updated. Commented Jan 1, 2019 at 18:19

2 Answers 2

3

You should have your header files decoupled to the greatest extent possible.

In particular, if foo.h is only ever going to be included by foo.c, it is unnecessary, and if it is used by other files, you will be pulling in potentially unneeded include files to them, which can:

  1. Increase compilation time (slightly - this is not necessarily a big concern these days)
  2. Require recompilation of more files than needed when header files change (which could take a significant amount of time for a large project)
1

The rule is: Every header file should be capable of being compiled on its own. If you have a file myheader.h, then a source file with a single line #include "myheader.h" should compile.

If your header file doesn't compile without including another header file, then include that other header file. However, there are cases where the problem can be fixed just by using a forward declaration like "class otherclass;", if that is a case then it is very much preferable.

So DON'T include header files without a need, and avoid the need if you can.

Why not include other header files that are only used by the source file? Because your header file is supposed to be shared with other files. It is supposed to contain things you want to share. Why would you want to share internal details of your source files, like what headers it needs? You should share as little as possible.

1
  • To be honest, this is a very weak argument. It boils down to “don’t do it because you shouldn’t” without giving any reasons. Commented Jan 1, 2019 at 21:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.