So I read up on the ordering of your includes, and this guy suggested you include your local header first so as to make sure it doesn’t have prerequisites. Ok, I get that. I’m on board. The whole compartmentalization thing is good.
But I’ve got this file, file.c which includes it’s file.h, which declares functions to save files. Which passes around the FILE* type used by fopen and friends.
If I include file.h before I include stdio.h then there’s an obvious parsing error when it’s building file.h because it doesn’t know about the FILE* type.
I know I’ve got to be missing something dirt simple, but I can formulate this into something google can use. Should I be doing something different in file.h? Is this simply something that needs to be included in a specific order? Thoughts?
If a header file such as file.h depends on other headers such as stdio.h, then file.h should #include those headers as necessary.
Each header file should keep track of its own dependencies, and use #include guards to prevent multiple translation if it winds up being included several times:
#ifndef FILE_H
#define FILE_H
#include <stdio.h>
...
void myfunc(FILE *);
...
#endif
This way the order of the includes simply doesn’t matter, which makes maintenance much less crazy-making.
7