Not even cstdint? Not including that would preclude writing functions with return types of uint16_t, etc.
but providing access to data type definitions (like stdint, but also custom types used in libraries or whatever) and compile-time configuration values are two important occasions where it makes sense.
This is the starting point to say that it is OK to allow #include in header files.
Do you mean build system dependencies? I.e., where a change to foo.h means you have to re-compile a bunch of implementation files?
Sort of. Yes it is to do with build dependencies but dependencies are related to module coupling. You want low coupling.
It's a common "requirement" that head files be "self-contained", which means that they should #include the files necessary to satisfy any symbols that they use.
This is a complete miss-understanding of the 'coupling principle'. Achieving low coupling is not the same as saying that a module must be 'stand alone'.
This is true for binary library modules BUT NOT in house software module being developed.
dependencies are easily managed by software. That's what the "make depend" step is for.
Yet another excuse.
How often do developer actually check the dependency tree?
How do developers know when a problem is starting when looking at the results of software to map the dependencies?
But the problem with that is that you have to add an include to each and every file which needs it and dependancies are less clear.
Actually the dependencies are absolutely clear.
By ONLY using includes in source files, the list of includes in the source file MUST be correct or it will not compile.
Therefore the list of #includes in a source file IS the list of dependent headers (assuming unnecessary includes have been removed).
It is now easy to always know what the dependencies are just by looking at the list.
You do not need to run tools to work out what the dependency is.
Let face it how often do developer actually look at the dependencies - this way they are always looking at it.
i have h files just to collect 5 - 10 #include in it because i hate to type 5 - 10 #include every time i create a c file.
I have a strict policy to have one include file which includes all other includes in the right order. This gets rid of the 'include hell' which quickly emerges when working on a larger project.
This may sound like the solution but it actually increases coupling. See the next quote and response :
By having a single file with all the includes, everything is now dependent
The problem is that it's easy to end up with false dependencies, especially if you don't separate function and type declarations. I'm sure most have experienced situations where touching a header file forces completely unrelated source files to be rebuilt.
This is exactly one of the problems that having #include in header files cause!
-how-deep-is-too-deep/?action=dlattach;attach=476456;image)
By allowing #include in header files, it is inevitable that you end up with the high coupling diagram.
Dissallowing #include in header files cannot stop the high coupling problem but it will force developers to look and think about it all the time.
Home
Help
Search
Login
Register
