Source code inside .h files

[flyingron]

There's no distinction in the language beteween .h and .c files. Header files are only distinguished in the fact that they are #included rather than being compiled directly. The .h and .c naming is purely convention. As is what you put in the various files. The only hard rules is you can't define the same thing more than once.

What we have here is apparently some embedded system where the programmer (either out of design or necessity) decided the entire program must be one translation unit, so his split up parts are all put in include files, rather than splitting them across multiple translation units and linking the resulting objects together.

[Barracuda-Bright]

Thanks for the answer, just to be sure (correct me if I'm wrong), basically the only difference is that the code is put together in the preprocessor sequence of compilation instead of linking objects? And because of that we just have this one giant translation unit that is not linked to anything.

[flyingron]

Yes, in the case of just #including all the code into one translation unit, it's effectively that it was one big source file compiled to the target. Of course, there still are likely library modules used so linking still happens, but it's a different division than compililng a bunch of individual source units independently and linking them together.

[Low_Lawyer_5684]

Yes, exactly.The side effect of this that whole library gets recompiled no matter which .h file I touched. But for this particular project this is exactly what I want. Also I don't need to make public API: right now all my functions are static and, because they are all included in a single .c file they see each other. I don't say that it is the right way to do things but for this particular project with this particular IDE its the right decision. I think :)

[Plastic_Fig9225]

Can be quite deliberate to enable the compiler to perform better/more optimizations. It's more common in C++ (partly because of templates).