21–27 of 27 posts
Earlier quoted context omitted.
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?
You can read some of the criticisms here https://en.m.wikipedia.org/wiki/Header-only
Earlier quoted context omitted.
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?
You can read some of the criticisms here https://en.m.wikipedia.org/wiki/Header-only
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.
What's with the majority of the code being in header files?
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?
Earlier quoted context omitted.
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?
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.
#if defined(__WIN32__) || defined(__WINRT__) || defined(_WIN64)
fopen_s(&file_to_read, path, "rb");
#else
file_to_read = fopen(path, "rb");
#endifThere is no need for this nonsense: #if defined(__WIN32__) || defined(__WINRT__) || defined(_WIN64) fopen_s(&file_to_read, path, "rb"); #else file_to_read = fopen(path, "rb"); #endif