Is there a way to detect when file dependencies are "accidentally" satisfied?

Question

Let's say there are three headers AAA.h, BBB.h and MyLib.h. MyLib.h needs to include both AAA.h and BBB.h to work properly.

Now, it just happens that BBB.h also includes AAA.h in it, but this is strictly due to the implementation, a detail that MyLib.h should not need to care about.

However, by mistake, the writer of MyLib.h neglects to include AAA.h and never notices. This normally doesn't result in an error or warning, for as far as I know. Later on, someone changes the implementation details of BBB.h so that AAA.h is no longer needed and thus removed. Now MyLib doesn't compile because internals of library BBB have changed.

Is there a way to error or warn in cases like these? I suspect (if this is even possible) that it would take some kind of annotation in the header being included.

Answer 1

I think it is best to avoid depending on other headers in public interface headers, so that this problem does not come up.

Public interface headers should not contain unnecessary definitions.

There are various tricks to do things without include files. For example, you can declare struct tags manually if you just need a pointer (libraries that only define a typedef frustrate this) and you can use _Bool instead of bool to avoid <stdbool.h>. Unfortunately, many important types such as size_t and uint32_t are only defined in headers.

Some packages go so far as to define their own foo_uint32_t using configure so they need not include <stdint.h> in their public interface headers. This is quite tricky since the types must be exactly the same to avoid confusion: even if sizeof(unsigned int) == sizeof(unsigned long) == 4 they are different types. Therefore, it may not be worth it.