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

  • 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 Jan 1 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 Jan 1 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. – James McLeod Jan 1 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 Jan 1 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. – user3629249 Jan 1 at 18:19
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.

  • 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. – James McLeod Jan 1 at 21:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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