6 ms·

This is as cool as it gets. I have a honest question about the source code, a lot of time since I coded anything meaningful in C, but I remember the header fil

This is as cool as it gets. I have a honest question about the source code, a lot of time since I coded anything meaningful in C, but I remember the header files did not have that much code on it, while here I see most of the code is in the header file. Why is this the case? Inline compilation? What are the advantages?

ur-whale 5y ago
Packing the entire library in a header file is a somewhat recent and much welcome trend. See for example: https://github.com/nothings/stb https://github.com/nothings/stb https://github.com/nothings/single_file_libs https://github.com/nothings/single_file_libs
- mkl 5y ago
  I wouldn't call it recent. Boost has been doing it since it was started in the late 1990s.
  - ChrisMarshallNY 5y ago
    The original C++ templates used to be entirely contained in the headers. I assume that is no longer the case, but it has been a long time, since I wrote C++. When I was writing template SDKs, the headers were pretty much the entirety of the library.
  - flohofwoe 5y ago
    Boost or C++ stdlib headers are different than STB-style single-file-libraries though in that the implementation code is inline and needs to be parsed each time the header is included.
  - tommiegannert 5y ago
    Boost did it because C++ template definitions must be in headers. That seems unrelated to this idea that C code using it is equally reasonable. That's a developer choice.
lifthrasiir 5y ago
There is a strong tradition of single-file C/C++ libraries [1] because it has been difficult to integrate larger C/C++ libraries into the codebase. [1] https://github.com/p-ranav/awesome-hpp https://github.com/p-ranav/awesome-hpp
- flohofwoe 5y ago
  There's an important difference between STB-style 'single file libraries', and C++ 'stdlib-style' header-only-libraries: STB-style libraries put the implementation code into a separate section inside an "#ifdef IMPLEMENTATION" block, while most C++ header-only-libraries use inline code (and thus pay a higher compilation cost each time this header is included). STB-style libraries skip the implementation already in the preprocessor and compile the implementation only once for the whole project.
  - sltkr 5y ago
    So what's the compelling reason to ship these as a single source file, instead of using the more logical and standard solution of a single header and a single source file? Unlike C++ header-only libraries, C libraries like this still need their implementation included exactly once. I understand the benefits of keeping the implementation in a single source file (simplifies integrating in existing build systems, interprocedural optimizations, etc.) but combining the source and header files too makes them awkward to use, with little benefit beyond being able to claim "our implementation is only 1 file!" which is about as impressive as saying "our implementation is only 1 line!" if you've just deleted all the whitespace.
    - flohofwoe 5y ago
      In general, STB-style headers simplify C/C++ build system shenanigans. E.g. one benefit is that you can configure the implementation via preprocessor defines without the defines leaking into the build system. Just add the config defines in front of the implementation include. It's also trivial to write "extension headers" which need to directly peek into the (otherwise private) implementation of the base library. Just include the extension header implementation after the base library implementation. PS: but also see: https://github.com/nothings/stb#why-single-file-headers https://github.com/nothings/stb#why-single-file-headers
CornCobs 5y ago
Single header libraries are hugely more ergonomic and easy to use. Just get the file, #include it and you're done! Most C libraries on GitHub prefer this mode of distribution now
- phkahler 5y ago
  >> Single header libraries are hugely more ergonomic and easy to use. Just get the file, #include it and you're done! Most C libraries on GitHub prefer this mode of distribution now I find that odd. How is that significantly better than dropping 2 files into a project and #including the header? A good build system should just compile all the C or C++ files in a given place, so nothing needs to be changed other than dropping the files in and #include where called from.
  - rytill 5y ago
    Why use two files instead of one?
    - bluedino 5y ago
      What if you want to use the functions in other C files? What if you want to compile them all separately?
      - hn_acc_2 5y ago
        1) Include it wherever it's used. The convention is to use the preprocessor[1] so it only appears once in the final binary 2) Most developers just want to compile to a single binary. Any developer who for some reason needs separately compiled objects should be able to quickly achieve that from a single-file library [1] https://github.com/phoboslab/qoi/blob/324c2243b2fb35f741a88d73ae10c132ccbba0b1/qoi.h#L158-L159 https://github.com/phoboslab/qoi/blob/324c2243b2fb35f741a88d...
  - hn_acc_2 5y ago
    The difference will be painfully clear once you try to walk a junior developer through installing and linking new files to a large project in Visual Studio, vs "copy this .h file here and include it". Whether or not a "good build system" should handle it, the fact that single-file libraries are much preferred these days should demonstrate most people don't have such a build system
clownpenis_fart 5y ago
a lot of people seem allergic to using the linker these days. As a result you have to inline all their code, which is usually ridden with warnings so you can't compile anymore with sane options like -Werror. It's not like using an actual library is really hard in the age of cmake and meson.

ur-whale 5y ago

Packing the entire library in a header file is a somewhat recent and much welcome trend. See for example: https://github.com/nothings/stb https://github.com/nothings/stb https://github.com/nothings/single_file_libs https://github.com/nothings/single_file_libs

mkl 5y ago
I wouldn't call it recent. Boost has been doing it since it was started in the late 1990s.
- ChrisMarshallNY 5y ago
  The original C++ templates used to be entirely contained in the headers. I assume that is no longer the case, but it has been a long time, since I wrote C++. When I was writing template SDKs, the headers were pretty much the entirety of the library.
- flohofwoe 5y ago
  Boost or C++ stdlib headers are different than STB-style single-file-libraries though in that the implementation code is inline and needs to be parsed each time the header is included.
- tommiegannert 5y ago
  Boost did it because C++ template definitions must be in headers. That seems unrelated to this idea that C code using it is equally reasonable. That's a developer choice.

lifthrasiir 5y ago

There is a strong tradition of single-file C/C++ libraries [1] because it has been difficult to integrate larger C/C++ libraries into the codebase. [1] https://github.com/p-ranav/awesome-hpp https://github.com/p-ranav/awesome-hpp

flohofwoe 5y ago
There's an important difference between STB-style 'single file libraries', and C++ 'stdlib-style' header-only-libraries: STB-style libraries put the implementation code into a separate section inside an "#ifdef IMPLEMENTATION" block, while most C++ header-only-libraries use inline code (and thus pay a higher compilation cost each time this header is included). STB-style libraries skip the implementation already in the preprocessor and compile the implementation only once for the whole project.
- sltkr 5y ago
  So what's the compelling reason to ship these as a single source file, instead of using the more logical and standard solution of a single header and a single source file? Unlike C++ header-only libraries, C libraries like this still need their implementation included exactly once. I understand the benefits of keeping the implementation in a single source file (simplifies integrating in existing build systems, interprocedural optimizations, etc.) but combining the source and header files too makes them awkward to use, with little benefit beyond being able to claim "our implementation is only 1 file!" which is about as impressive as saying "our implementation is only 1 line!" if you've just deleted all the whitespace.
  - flohofwoe 5y ago
    In general, STB-style headers simplify C/C++ build system shenanigans. E.g. one benefit is that you can configure the implementation via preprocessor defines without the defines leaking into the build system. Just add the config defines in front of the implementation include. It's also trivial to write "extension headers" which need to directly peek into the (otherwise private) implementation of the base library. Just include the extension header implementation after the base library implementation. PS: but also see: https://github.com/nothings/stb#why-single-file-headers https://github.com/nothings/stb#why-single-file-headers

CornCobs 5y ago

Single header libraries are hugely more ergonomic and easy to use. Just get the file, #include it and you're done! Most C libraries on GitHub prefer this mode of distribution now

phkahler 5y ago
>> Single header libraries are hugely more ergonomic and easy to use. Just get the file, #include it and you're done! Most C libraries on GitHub prefer this mode of distribution now I find that odd. How is that significantly better than dropping 2 files into a project and #including the header? A good build system should just compile all the C or C++ files in a given place, so nothing needs to be changed other than dropping the files in and #include where called from.
- rytill 5y ago
  Why use two files instead of one?
  - bluedino 5y ago
    What if you want to use the functions in other C files? What if you want to compile them all separately?
    - hn_acc_2 5y ago
      1) Include it wherever it's used. The convention is to use the preprocessor[1] so it only appears once in the final binary 2) Most developers just want to compile to a single binary. Any developer who for some reason needs separately compiled objects should be able to quickly achieve that from a single-file library [1] https://github.com/phoboslab/qoi/blob/324c2243b2fb35f741a88d73ae10c132ccbba0b1/qoi.h#L158-L159 https://github.com/phoboslab/qoi/blob/324c2243b2fb35f741a88d...
- hn_acc_2 5y ago
  The difference will be painfully clear once you try to walk a junior developer through installing and linking new files to a large project in Visual Studio, vs "copy this .h file here and include it". Whether or not a "good build system" should handle it, the fact that single-file libraries are much preferred these days should demonstrate most people don't have such a build system

clownpenis_fart 5y ago

a lot of people seem allergic to using the linker these days. As a result you have to inline all their code, which is usually ridden with warnings so you can't compile anymore with sane options like -Werror. It's not like using an actual library is really hard in the age of cmake and meson.