3 ms·

I know that using .c and .h files is the traditional way of doing it in C, and I started the engine this way, but to be honest, is there any gain to it in this

I know that using .c and .h files is the traditional way of doing it in C, and I started the engine this way, but to be honest, is there any gain to it in this scenario? The headers are library code, and having more files just means more maintenance and build complexity. Is there another advantage I am not aware of?

jdmoreira 7y ago
You can read some of the criticisms here https://en.m.wikipedia.org/wiki/Header-only https://en.m.wikipedia.org/wiki/Header-only
- macleginn 7y ago
  None of them seem relevant for a small-scale unitary project.
  - chongli 7y ago
    Even a large project like SQLite is provided as a single, unified header file!
- flohofwoe 7y ago
  A better resource is this: https://github.com/nothings/stb/blob/master/docs/stb_howto.txt https://github.com/nothings/stb/blob/master/docs/stb_howto.t... There's an important difference between C++ style header-only libs, where the implementation is often done in inline code (especially for template-heavy APIs) and thus visible in each compilation unit (which is indeed bad for compile times), and "STB-style single-file libs", where the implementation is only visible in a single compilation unit. The difference between a single .h file and a .h/.c pair is really just different packaging for distribution and integration into projects.
flukus 7y ago
The question should probably be what you gain from the header files? If you just want the simplicity you can "#include \"some_file.c\"" instead. Functionally it's no different, but it's less surprising to other people and it's an easier transition to a real build system if/when you need it. I think the reason it's being raised is because people think your writing a header only library.
- ryanpcmcquen 7y ago
  In my experience, including `"some_file.h"` is more common than `"some_file.c"`. I also like knowing at a quick glance what the entry point/main file is. That's less explicit when all the files have the same extension.

jdmoreira 7y ago

You can read some of the criticisms here https://en.m.wikipedia.org/wiki/Header-only https://en.m.wikipedia.org/wiki/Header-only

macleginn 7y ago
None of them seem relevant for a small-scale unitary project.
- chongli 7y ago
  Even a large project like SQLite is provided as a single, unified header file!
flohofwoe 7y ago
A better resource is this: https://github.com/nothings/stb/blob/master/docs/stb_howto.txt https://github.com/nothings/stb/blob/master/docs/stb_howto.t... There's an important difference between C++ style header-only libs, where the implementation is often done in inline code (especially for template-heavy APIs) and thus visible in each compilation unit (which is indeed bad for compile times), and "STB-style single-file libs", where the implementation is only visible in a single compilation unit. The difference between a single .h file and a .h/.c pair is really just different packaging for distribution and integration into projects.

flukus 7y ago

The question should probably be what you gain from the header files? If you just want the simplicity you can "#include \"some_file.c\"" instead. Functionally it's no different, but it's less surprising to other people and it's an easier transition to a real build system if/when you need it. I think the reason it's being raised is because people think your writing a header only library.

ryanpcmcquen 7y ago
In my experience, including `"some_file.h"` is more common than `"some_file.c"`. I also like knowing at a quick glance what the entry point/main file is. That's less explicit when all the files have the same extension.