#include's in multiple modules

I am working on a relatively big program that is divided in multiple modules, and I just want to know:

Which is more program efficient? Writing a header file that has all the #include's the program needs, or #include'ing the necessary files for each module separately? The thing is that I am not sure if the compiler preprocesses every single module first and them compiles them all together, or if the compiler preprocesses the modules and compiles them seperately.

Thanks.

The order or number of #includes make no difference towards "program efficiency". They are a compile-time thing, not a run-time thing.

Todd

cool... so even If I include useless header files, the compiler will not use them if it doesn't need too?

That's for the linker to decide. The final step in compiling an executable or library.

Even multiple inclusion compile-time performance issues are usually handled
cleanly from the compiler, include-guards or #pragma once are probably just
as efficient nowdays.

Thanks.

> or #include'ing the necessary files for each module separately?
This would be my preference, because
- it's obvious from looking at the code what the module actually depends on. #include "everything.h" tells you nothing, should you ever want to take your module and re-use it somewhere else.
- a single catch-all include will necessarily have to include things which modules don't need, so there is an incremental cost in the compilation time of each module.
- if you change just ONE header which everything.h includes, then you have to recompile the ENTIRE project.

A consequence of only including the headers you need is that if forces you to think about what you're doing. The need to include a header might alert you to your interfaces and code structure being broken.

> Writing a header file that has all the #include's the program needs,
If you're lazy, and your compiler supports precompiled headers, then it may work for you.

Quote:

---

Originally Posted by Salem

- a single catch-all include will necessarily have to include things which modules don't need, so there is an incremental cost in the compilation time of each module.

---

That is, unless it's a precompiled header.

Quote:

---

Originally Posted by Salem

> Writing a header file that has all the #include's the program needs,
If you're lazy, and your compiler supports precompiled headers, then it may work for you.

---

However, you should still beware, since changing a header which is included in a precompiled header still triggers this condition:

Quote:

---

- if you change just ONE header which everything.h includes, then you have to recompile the ENTIRE project.

---

Thanks a lot for the explanation. I'll keep that in mind.

Quote:

---

Originally Posted by samus250

Which is more program efficient? Writing a header file that has all the #include's the program needs, or #include'ing the necessary files for each module separately?

---

In general, a header file should include all the headers it requires internally (which basically boils down to data types which are referenced in the header file), and a source module should also include any headers it requires. It's not good to depend on one header pulling in another header, even if you know that it does, because that may change in the future.

This can lead to "redundant" inclusion of headers, but it's harmless and far preferable to the alternative, where you have to guess which header might possibly pull in which other header.