If I have data types defined as function arguments in header files, I need to include the headers for those data types. There's apparently no way around this, and it does result in messy dependencies.
I'm just curious if large projects have a systematic way of dealing with the dependency tree created by having fine-grained compilation units.
The simplest way to write a C program is as a single file. Then you have none of these problems, other than it's very difficult to navigate through the code as nothing is separated by functional area, and you have to recompile the whole program for every small change.
Next in the complexity chain, you could break apart the single C file into multiple .c files and include them in the right order, and not use header files at all. However, that still requires that you recompile the whole program for every change.
So now we're down to compiling every separate .h/.c entity as its own object file to speed up compilation, but structuring these files so that they compile and include everything in the correct order becomes a much bigger problem.
There are other data types besides pointers to structs. Specifically, stdint.h data types are a good example (on linux).
int
myfunction(uint64_t arg0);
When writing cross-platform code, there are typically a lot of these kinds of things going on.
Also, I typically include data type definitions in header files if they're used in more than one context. If I define a new data type in a header file that depends on other data types, I have to include those headers in the header file.
Let's say I'm writing an encoder/decoder for a protocol and I want to separate the encode functions from the decode functions. Maybe they're in separate programs. They'll both use the same data structures for the most part.
It it's a network protocol the layers of dependencies can get pretty deep.
This isn't a problem with a one-liner solution, it's "how do you structure a huge project to reduce weird dependency issues when compiling while keeping the code readable?"
I'm just curious if large projects have a systematic way of dealing with the dependency tree created by having fine-grained compilation units.
The simplest way to write a C program is as a single file. Then you have none of these problems, other than it's very difficult to navigate through the code as nothing is separated by functional area, and you have to recompile the whole program for every small change.
Next in the complexity chain, you could break apart the single C file into multiple .c files and include them in the right order, and not use header files at all. However, that still requires that you recompile the whole program for every change.
So now we're down to compiling every separate .h/.c entity as its own object file to speed up compilation, but structuring these files so that they compile and include everything in the correct order becomes a much bigger problem.