stb

> In general, STB-style headers simplify C/C++ build system shenanigans. Too vague. How is it better, concretely? > E.g. one benefit is that you can configure the implementation via preprocessor defines without the defines leaking into the build system That's not a benefit. How is this: #define LIB_IMPLEMENTATION #define LIB_KNOB 123 #include "lib.h" Any better than the two-file version: #define LIB_KNOB 123 #include "lib.c" ? > 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. I'm not sure what this means. Can you give an example? Is this being used in the above library? > PS: but also see: https://github.com/nothings/stb#why-single-file-headers

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

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/single_file_libs

C relies vastly on dynamic linking. C++ cannot dynamically link templates, so it's pretty common for a C++ library to be made entirely of header files. Also, that's really only true of a small number of Linux and BSD flavors. Applications shipped on Windows, macOS, Android, iOS, or any of the Linux "application bundle" systems like the Steam runtime, Docker, FlatPak, will deliberately avoid using globally-specified dependencies. It's also commonplace to avoid declaring dependencies in C by vendoring them, like how VLC basically includes its own implementation of a bunch of data structures [1], and the entire universe of single-file libraries [2]. [1]: https://wiki.alopex.li/LetsBeRealAboutDependencies#gotta-go-... [2]: https://github.com/nothings/stb/blob/master/docs/stb_howto.t...

For my use, alpha is what I tend to miss in PPM. There's the PAM extension [0] but it's not nearly as widely supported as basic PPM. Usually at that point, I reach for PNG via stb_image_write [1]. [0] https://en.wikipedia.org/wiki/Netpbm#PAM_graphics_format [1] https://github.com/nothings/stb/blob/master/stb_image_write....

The language itself is a little unreadable at first glance, but the idea of it is a very good one. sbt [1] is an amazing project for small embeddable toy programs, but using fuzzers rapidly shows how unsafe the code is, and the benchmarks in the original article show the extent of performance compromises made to make it work. It seems like this would be an interesting approach to a lot of security programming where it involves data structures, since those have typically been a source of issues. Having a memory-safe ASN.1 parser would be really nice, considering how much difficulty that has caused in the security space. With a lot of security programming there's a reliance on constant-time algorithms, which this may not be well-suited to, however. [1] https://github.com/nothings/stb

> I collect different C libraries as a personal stash of toolkits Might you have a write-up or link for these, and if so might you be willing to share it? I have been using Sean Barrett's libraries [0], as well as his curated list of other people's single-header libraries [1], and, like you, I am always on the lookout for new things to add to the collection :) [0] https://github.com/nothings/stb [1] https://github.com/nothings/single_file_libs

For the general reasons. https://github.com/nothings/stb#why-single-file-headers