[ryanpcmcquen]

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?

[flukus]

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]

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]

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

[macleginn]

None of them seem relevant for a small-scale unitary project.

[chongli]

Even a large project like SQLite is provided as a single, unified header file!

[flohofwoe]

A better resource is this:

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.