See the top part of the header file, where all the function and type declarations are? That's the header. Just move everything below it to a c file.
See the top part of the header file, where all the function and type declarations are? That's the header. Just move everything below it to a c file.
This particular library doesn't seem to follow the STB convention where the implementation is inside an #ifdef IMPLEMENTATION block, but that would be trivial to fix.
Once you have that it's just as trivial to use from other languages as a regular .h/.c library, just include the implementation into a C source file and compile that into a static link library or DLL, then include the declarations (without IMPLEMENTATION define) into your language (if the language can directly include C headers) or use the header to auto-generate the bindings.
For example:
- https://github.com/floooh/sokol-zig
- https://github.com/floooh/sokol-nim
- https://github.com/floooh/sokol-odin
These are all auto-generated from STB-style single-file libraries: https://github.com/floooh/sokol
mv mylib.h mylib.c
gcc -c mylib.c -o mylib.o
Then link it as a .so/.dll or in a .a library. Done you can use it like any other library.I do also like easily embeddable tech like imgui, or lua, where you can simply copy the source code in your source tree.
How come we have managed during the last 40 years?
Yeah we managed, I never said the opposite. I only talked about why I liked header-only libs: because I just copy/paste the source in my source tree, regardless of the build system I use.
If I'm using CMake, and a library is using autotools, I'll have to rewrite the lib's build system, and maintain it. I'm too lazy for that.
Nowadays, use cmake + conan/vcpkg as alternative as well.
Do we need to spoon-feed everything?
Also it is a toy library in size, then there are those that can be used to stress test compilers.
If I have a template header .hpp and I do not wish to specialize the template function bodies in a .cpp file, the template header function bodies must be declared in the .hpp, right?
Yes it needs to be on the header, however depending on what is the goal, many operations could eventually be delegated to helper functions or PIMPL classes, which aren't fully exposed on the header.
And for the lucky users of VC++ 2022, there is also the option to use modules instead, where templates are then exposed via the module metada.
Thanks for your comment.
I will have to dig in to modules in due course.
https://github.com/nothings/stb
Important difference to typical C++ header-only libs: STB style libs don't use the inline keyword, but instead place the implementation into an ifdef/endif block.
It's really just for easier distribution and integration, and the difference to a single .h/.c pair isn't all that big.
Definitely not big enough to get all riled up about it - the actual problem are libraries that come in dozens of source and header files and with their own build system files, or C++ libraries which put the implementation into inline code, like most C++ stdlib headers (because this increases compilation time for every file which includes such a header).
Why? Can't you make a shared object just as easily?