I am currently working on program with a lot of source files. Sometimes it is difficult to keep track of what libraries I have already #include
d. Theoretically, I could make a single header file called Headers.h
that just contains all the #include
statements I need, then make all other header files #include "Headers.h"
.
Why is this a good/bad idea?
Pros:
Cons:
On the whole I would not recommend that approach. The last con listed above it particularly important.
Best practice would be to include only headers that are needed for the code in each file.
In complement of Harmic's answer, indeed the main issue is the build system (most builders work on file timestamp, not on file contents. omake
is a notable exception).
Notice that if you only care about many dependencies, GNU make can be used with autodependencies, together with -M* options passed to GCC (i.e. to g++
and actually to the preprocessor).
However, many libraries are offering to their user a single header (e.g. <gtk/gtk.h>
)
Also, a single header file is more friendly to precompiled headers technology. In particular, GCC wants a single header for precompilation.
See also ccache.
Tracking all the required includes would be more difficult as they are abstracted from their c source files and not really supporting modularisation pus all the cons from #harmic
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With