4 ms·

A is something I want to use in multiple files, like a method declaration, a type, a const or a preprocessor define. B is a place that I want to use it, and it

A is something I want to use in multiple files, like a method declaration, a type, a const or a preprocessor define. B is a place that I want to use it, and it's tightly related to A. Unfortunately, B belongs in a .c file. But to use A in multiple places, it belongs in a .h file. Crap, now these two very related things that I wanted to keep together lexically must now be split into separate files. In this case, the author is making a super-simple example project. I'm happy they chose to forgo the standard C header/source file dance. It made it a lot easier to read and understand. But yeah, the dance is required for "real" projects, as you've described.

RealityVoid 7y ago
The way I view it is the following: - Put everything in the C file. - If you need a function visible outside, put it's _prototype_ in the .h file. - If you want to have a variable visible outside, also make a extern declaration inside the .h file. - If you want to have anything else visible to the outside, just move it to the .h file. The reason I say that putting functions inside a .h file is a pain is because of the way the preprocessor works. It takes the contents of the included file and pastes it at the place of the include. 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. At link time the linker will be confused because it will not know about witch of the functions you're talking about when you call it. So then you declare it static, but then you _actually_ have 2x functions inside your executable, that do the same thing. This is even worse with variables declared static inside .h files since here you will think you're changing your variable, but you actually have separate variables inside each compiled file. Of course, my observation is also based on taste. I like when I have everything inside one file, instead of spread over multiple files( of course, as long as this is reasonable). This program here might have had one single .c file and it would have been just file. I actually would have considered it easier to read, but as I said, it's a matter of taste at this point.
- krychu 7y ago
  Duplicating some code in the executable of this size might not be that much of a deal. I wonder if there are examples where such practice resulted in improved performance due to locality of the code. Of course you could also toy with inlines.
- 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 ago
      Why would a competent developer use this .h multiple times? These arguments hinge on the Dev being pretty careless.
      - limomium 7y ago
        Ah 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.

RealityVoid 7y ago

The way I view it is the following: - Put everything in the C file. - If you need a function visible outside, put it's _prototype_ in the .h file. - If you want to have a variable visible outside, also make a extern declaration inside the .h file. - If you want to have anything else visible to the outside, just move it to the .h file. The reason I say that putting functions inside a .h file is a pain is because of the way the preprocessor works. It takes the contents of the included file and pastes it at the place of the include. 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. At link time the linker will be confused because it will not know about witch of the functions you're talking about when you call it. So then you declare it static, but then you _actually_ have 2x functions inside your executable, that do the same thing. This is even worse with variables declared static inside .h files since here you will think you're changing your variable, but you actually have separate variables inside each compiled file. Of course, my observation is also based on taste. I like when I have everything inside one file, instead of spread over multiple files( of course, as long as this is reasonable). This program here might have had one single .c file and it would have been just file. I actually would have considered it easier to read, but as I said, it's a matter of taste at this point.

krychu 7y ago
Duplicating some code in the executable of this size might not be that much of a deal. I wonder if there are examples where such practice resulted in improved performance due to locality of the code. Of course you could also toy with inlines.
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 ago
    Why would a competent developer use this .h multiple times? These arguments hinge on the Dev being pretty careless.
    - limomium 7y ago
      Ah 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.