Is it a good idea to include all of your inclusions in a single header file?

What is the best practice for C that you put in the C header file?

Is it useful to use all the files included in the program for several source files in one header file?

What about the inclusions that are used in almost every file (i.e. stdio.h)?

+7
source share
7 answers

Not. It just adds cool and overhead.

One of the biggest problems you will encounter as an maintainer is figuring out which headers don't need to be included and getting rid of them. You fall into a list of 20 + headers, you begin to contemplate ugly things , like rude coercion through it (removing one at a time and observing if something breaks).

Be kind to people who should support your things in the future. Use the headers you need for each module, no more ... no less :)

+11
source

I personally subscribe to the philosophy of "put it where you use it." This makes it clearer which files use what depends on dependencies, etc.

Imagine you have the title MyHeader.h . If you make changes to it that require changing the code that relies on it, it is easy to find this dependent code, if every file that uses it has #include "MyHeader.h" - you can simply do a global search for the include statement.

If, on the other hand, you include only MyHeader.h in a different header, MyHugeHeader.h , and then include in your files you cannot do the same, since everything in files using MyHeader.h is #include "MyHugeHeader.h" , like any other file.

+3
source

Including all possible headers in one application header is just as wrong as wrong.

This is laziness that comes at a great price. It makes assemblies fragile. This makes it difficult to understand the true dependencies and, therefore, it is difficult to refactor or otherwise reuse the code.

This makes testing difficult.

But the biggest problem is that it represents intellectual laziness and encourages more of the same.

Like all programming problems, do what you need, no more, no less. Think about saving. Think about construction management.

Just THINK.

+3
source

Personal preferences are really ... It doesn't matter how it is formatted as long as you are incompatible (which makes reading easier). You can put it all in 1 header file, or you can just put it in every file he needs. It also depends on how all the others are loaded, what comes after main does not need to be included, etc. Therefore, using the same header file for ALL of your other files, C may or may not (depends from the compiler) include the same include multiple times.

Edit: I also need to agree with the Mac, put it where you use it, this is also a very good thing.

+1
source

Some things not already mentioned:

  • unnecessary dependencies add to compile time. When you change the title, you will have to recompile all compilation units that include this directly or indirectly. If inclusion is not required, recompilation is also not. The larger your program, the greater the problem, especially if you violated your programs in composers whose recompilation must be started manually.

  • Precompiler headers can be more efficient when adding unnecessary dependencies.

+1
source

I would not intentionally put all of my included in a single header file simply because if you change one of these included header files, you will have to recompile everything that includes your file with a "leading" inclusion. This can lead to unnecessarily long compilation times for changing one line.

However, I would not devote too much time to making sure that I am not too liberal with statements. Some engineers will spend a lot of time reducing the number of inclusions in order to save compilation time, and I think that their time is better at solving problems or working on new features.

+1
source

The header file is actually what you include c in your program. It contains data structures such as structures, macros, function definitions, etc. Sometimes a single header file may be fine; buy, if your program turns into logical components, you may need more.

0
source

All Articles