Reputation: 10144
If a project has a header that includes a second header and both of them include a common header, is it good practice to drop the inclusion of the common header from the first header and rely on the indirect inclusion via the second header?
e.g.:
I know the stdint.h
can be removed from temperature.h
, but should it be?
In temperature.h
:
#include <stdint.h> // *Should* this include be removed in this case.
#include "i2c.h"
extern uint16_t temperatureRead (i2cData_t x);
In i2c.h
:
#include <stdint.h>
typedef struct i2cData_t {
uint16_t exampleMember
} i2cData_t;
Upvotes: 4
Views: 1409
Reputation: 16086
Generally you want your modules to be self contained. If your module relies on something in a header then include it. Temperature.h may one day decide it doesn't need to include stdint.h any more and have it removed. Your code should have nothing to do with that decision, so safeguard it by including stdint.h, i.e. be self contained.
Use header guards (or C++ pragma once) to make sure your compilation speed doesn't degrade due to including a header multiple times.
Upvotes: 5
Reputation: 121961
I know the stdint.h can be removed from temperature.h, but should it be?
Each source file should include the headers that it explicitly requires. In the posted case, if the type of exampleMember
changed to be int
and ic2.h
no longer includes stdint.h
then the compliation of temperature.h
fails, even though its source is unchanged. Or, if temperature.h
is used by other source files then those other source file must include stdint.h
in order for compliation succeed.
Upvotes: 3
Reputation: 9340
IMO, no.
Always assume a module is standalone. In above case, temperature.h requires stuffs from both stdint.h and i2c.h so let it be. In case a refactoring happens and i2c.h no longer includes stdint.h, you can avoid compilation problem. It's simple to fix for a small project, but not quite for a big one.
Upvotes: 3