2

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()
{
yeliabhcaz
  • 31
  • 4
  • 2
    because .h files contain only definitions and you need these definitions to make other parts of your program work. But it's acutally declarations that use most of the includes => so you should keep them only where they will be used , else you will share a lot of unnecesary files at every `include` – Ivan Apr 01 '21 at 21:24
  • If you put as few includes as possible in a header file, the amount of dependencies that gets "pulled in" when you include it is keept to a minimum. This is anywhere from unimportant to very important depending on the size of your project. – super Apr 01 '21 at 21:27
  • there's actually a [great answer here](https://stackoverflow.com/a/52929173/11261546) which was already in duplicate of another [great answer](https://stackoverflow.com/a/583271/11261546) – Ivan Apr 01 '21 at 21:49
  • A good rule of thumb is to `#include` the headers directly required in a header, and only those. What that means is that a simple `test.cpp` file with just one line `#include "header.h"` should compile as-is. And if, for example, `header.h` does `#include ` but `test.cpp` compiles even if you comment out that line, then `#include ` does not belong in `header.h` and can be left out. – dxiv Apr 01 '21 at 23:23

3 Answers3

4

There are a few considerations:

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

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

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

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

Chris Uzdavinis
  • 6,022
  • 9
  • 16
  • Thank you very much for that. I wasn't even thinking about other people using the header and causing collisions there. It definitely makes sense to only include anything that another user wouldn't already have in their code. – yeliabhcaz Apr 01 '21 at 22:02
0

Only put the minimum required #include in a .h file. That way you prevent unexpected code collisions and unnecessary make dependencies.

chux - Reinstate Monica
  • 143,097
  • 13
  • 135
  • 256
0

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.

David Marquant
  • 2,039
  • 14
  • 12
  • I agree the difference is not even "notorious" in small projects, but it's not a good a practice anyway – Ivan Apr 01 '21 at 21:35