4 ms·

What's with the majority of the code being in header files?

Koshkin 7y ago
Good question... (In fact, a small project with a single .c file does not even need include files.)
microcolonel 7y ago
I think Ryan just wants a single compilation unit, for the time being. I would personally just put all the code in one file if it's this small (though I think some text editors are not good at editing one file from multiple views, so I can see that being annoying for some).
ryanpcmcquen 7y ago
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.
babuskov 7y ago
Using header files is great when starting new projects. When I wrote my first game engine, I tried to keep everything in .h files. There are two benefits: A minor one, but still saves some time: You don't have to think about build system. Just compile a single .c file on the command line. You can quickly add and remove .h files while prototyping, without having to add/remove files to the project. A major one: is that you cannot create cyclic dependencies. This helps to get your call hierarchy right. When using header files only, the only way to get cyclic dependency is to use a forward declaration and every time you feel like you need to do that, a big red flag is raised in your mind. And then you start to think how to do it properly. This is even more important in C++ where you have to think about responsibilities of every class. It prevents you from creating too coupled code. When the project grows and compilation times get long, you should split all of those into separate compilation units, so that you can use multi-threaded builds (via ninja, or make -j).
- pjmlp 7y ago
  File->New Project isn't that hard.
pjmlp 7y ago
Not bothering to learn how to deal with compiler toolchains.
w0utert 7y ago
It's not uncommon in game development to do 'unity builds', by basically including all code to get a single compilation unit. It can reduce build times and the compiler has more options for optimizations (inlining, mostly). This doesn't require putting everything in header files, just including the .c files gets you the same result. But if you're doing unity builds the distinction between header files and source files is basically reduced to the file extension anyway...

Good question... (In fact, a small project with a single .c file does not even need include files.)

I think Ryan just wants a single compilation unit, for the time being. I would personally just put all the code in one file if it's this small (though I think some text editors are not good at editing one file from multiple views, so I can see that being annoying for some).

ryanpcmcquen 7y ago

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.

babuskov 7y ago

Using header files is great when starting new projects. When I wrote my first game engine, I tried to keep everything in .h files. There are two benefits: A minor one, but still saves some time: You don't have to think about build system. Just compile a single .c file on the command line. You can quickly add and remove .h files while prototyping, without having to add/remove files to the project. A major one: is that you cannot create cyclic dependencies. This helps to get your call hierarchy right. When using header files only, the only way to get cyclic dependency is to use a forward declaration and every time you feel like you need to do that, a big red flag is raised in your mind. And then you start to think how to do it properly. This is even more important in C++ where you have to think about responsibilities of every class. It prevents you from creating too coupled code. When the project grows and compilation times get long, you should split all of those into separate compilation units, so that you can use multi-threaded builds (via ninja, or make -j).

pjmlp 7y ago
File->New Project isn't that hard.

pjmlp 7y ago

Not bothering to learn how to deal with compiler toolchains.

w0utert 7y ago

It's not uncommon in game development to do 'unity builds', by basically including all code to get a single compilation unit. It can reduce build times and the compiler has more options for optimizations (inlining, mostly). This doesn't require putting everything in header files, just including the .c files gets you the same result. But if you're doing unity builds the distinction between header files and source files is basically reduced to the file extension anyway...