4 ms·
>So doing a function inside a .h file and using it inside multiple .c files will mean you have the same function multiple times and it will throw a linker error
by fit2rule 7y ago
>So doing a function inside a .h file and using it inside multiple .c files will mean you have the same function multiple times and it will throw a linker error if the function is not static.
This is prevented by a header guard.
And, also: if you have the same function defined elsewhere, and your compiler complains about it: good. That is a bug.
Single-header projects like this are useful because they can be very easily integrated - just include the header, and build. No need to add another .c to the project, get its compile and link target inserted in the project. The single-.h approach makes sense for a project like this, where indeed the purpose is to put an embedded language/compiler, with as little fuss as possible, in any particular C-based project.
If the author caters to the desire to scratch the convention itch, and moves everything to .c - this just adds another layer of cyclomatic complexity to the project management. I'm a lot more inclined to try out such a radically useful project if its a single header - or can be expressed as a single header - than if I have to edit my project, add new .c targets, get the linking done properly, etc. Single .h with header guards - done properly (i.e. namespace) - can make such projects immediately more attractive than if it comes with a heavy load to integrate ..
- RealityVoid 7y ago> This is prevented by a header guard. This is false. A header guard will prevent a .h file being included multiple times inside a .c file. It will not prevent a .h file being included in multiple .c files because each .c file is its own compilation unit (well, usually at least). It doesn't even make sense preventing a .h file being included in multiple .c files because what purpose would a .h file even have then?
- fit2rule 7y agoWhy would a competent developer use this .h multiple times? These arguments hinge on the Dev being pretty careless.
- limomium 7y agoAh yes, the mythical competent C developer; Who knows all the corner cases, implementation details and never makes mistakes? This bridge doesn't need guard rails. A competent pedestrian wouldn't walk off the edge.
- sigjuice 7y agoWhy can't a competent developer add one more .c file to their current collection of .c files?
- MaxBarraclough 7y ago> Why would a competent developer use this .h multiple times? Transitivity. When you include a header file, it might include other header files. There are no real restrictions on what other header files it might include, as they may be part of the implementation, rather than the interface. We see this particularly clearly in C++, where private members and member-functions must be declared in header files. The header files included by a header file, may change across versions. Obviously, we don't want to omit any of our #includes just because a library we use happens to include it. This wouldn't solve our problem anyway, though: different headers may overlap in the headers they include. This means it must be safe to include a header several times (i.e. inclusion of a header file must be idempotent). Diligence isn't enough. Fortunately, it's trivial to do this with the 'header guard' pattern (#ifndef MY_HEADER_H...)