29 ms·

Please stop making "header only libraries": they're nontrivial to bind to from non-C languages. You have to basically either split them up yourself or embed a C

Please stop making "header only libraries": they're nontrivial to bind to from non-C languages. You have to basically either split them up yourself or embed a C compiler in your compiler. 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.

pjmlp 4y ago
I really don't get this trend of using C and C++ as "scripting" languages, what a laziness to learn how to work with compilers.
esrauch 4y ago
It turns out that regular libraries are nontrivial to use from C though, due to no standardized build system. Should a C library optimize for usage from C or non-C languages?
- deleted 4y ago
  [deleted]
whateveracct 4y ago
Hm in Haskell I prefer single-header. I can just copy it into my repo and it Just Works. I guess Haskell does have really good C interop. Both the FFI and hsc2hs make for seamless interop. It even understands pkg-config - it doesn't embed anything in the compiler though. Just understands the ecosystem. It's to the point where I consider C a DSL you can use.
kevin_thibedeau 4y ago
This is a C++-ism that has no place in C (and overused in C++).
- pjmlp 4y ago
  Even on C++, regardless of templates, most code doesn't need to be header only, other than laziness to properly learn how to work with compilers and build systems.
  - eliasmacpherson 4y ago
    Hello. Forgive my ignorance and possible misunderstanding of your 'most code' qualifier. 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?
    - pjmlp 4y ago
      Yes and no. 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.
      - eliasmacpherson 4y ago
        Helper functions, PIMPL, that's all fine - the declaration and function body of the template is still defined in the .hpp. Whether all of the body of the template is also defined there was not my concern in asking. Thanks for your comment. I will have to dig in to modules in due course.
- linkdd 4y ago
  The lack of C or C++ build system makes me prefer header-only libraries, like nlohmann/json, entt, etc... I do also like easily embeddable tech like imgui, or lua, where you can simply copy the source code in your source tree.
  - pjmlp 4y ago
    If anything there are plenty of options. How come we have managed during the last 40 years?
    - linkdd 4y ago
      I should have said: the lack of standardized build system. CMake is a pain, Bazel, vcpkg, autotools, plain old Makefiles, etc... All of them do not match the developer experience of npm, cargo, etc... 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.
      - pjmlp 4y ago
        You should have installed it already via the OS package system, or the modern alternative, conan/vcpkg.
    - flohofwoe 4y ago
      It was a massive pain in the butt in that time. Just try to intregrate a "standard library" like libjpeg or libpng into your cross-platform project. That's exactly why everybody has switched over to stb_image.h to quickly load image data without hassle.
      - pjmlp 4y ago
        Easy, have your "load/save_image" calls the OS provided APIs for image handling, while on UNIX assume the libjpeg-dev or libpng-dev are already installed via the OS package system, have the makefile targets adjusted as needed per platform. Nowadays, use cmake + conan/vcpkg as alternative as well. Do we need to spoon-feed everything?
- flohofwoe 4y ago
  The most popular "header only" (or rather "single file" libs) are mostly written in C though: https://github.com/nothings/stb 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).
matheusmoreira 4y ago
> "header only libraries": they're nontrivial to bind to from non-C languages. Why? Can't you make a shared object just as easily?
linkdd 4y ago
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.
- FeepingCreature 4y ago
  I still need to parse the header. For 90% of libraries you can just parse the subset of C that's required for function declarations.
  - linkdd 4y ago
    https://github.com/eliben/pycparser https://github.com/eliben/pycparser
flohofwoe 4y ago
> they're nontrivial to bind to from non-C languages 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-zig - https://github.com/floooh/sokol-nim https://github.com/floooh/sokol-nim - https://github.com/floooh/sokol-odin https://github.com/floooh/sokol-odin These are all auto-generated from STB-style single-file libraries: https://github.com/floooh/sokol https://github.com/floooh/sokol
- FeepingCreature 4y ago
  Oh yeah that'd do it. Good point.

pjmlp 4y ago

I really don't get this trend of using C and C++ as "scripting" languages, what a laziness to learn how to work with compilers.

esrauch 4y ago

It turns out that regular libraries are nontrivial to use from C though, due to no standardized build system. Should a C library optimize for usage from C or non-C languages?

deleted 4y ago
[deleted]

whateveracct 4y ago

Hm in Haskell I prefer single-header. I can just copy it into my repo and it Just Works. I guess Haskell does have really good C interop. Both the FFI and hsc2hs make for seamless interop. It even understands pkg-config - it doesn't embed anything in the compiler though. Just understands the ecosystem. It's to the point where I consider C a DSL you can use.

kevin_thibedeau 4y ago

This is a C++-ism that has no place in C (and overused in C++).

pjmlp 4y ago
Even on C++, regardless of templates, most code doesn't need to be header only, other than laziness to properly learn how to work with compilers and build systems.
- eliasmacpherson 4y ago
  Hello. Forgive my ignorance and possible misunderstanding of your 'most code' qualifier. 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?
  - pjmlp 4y ago
    Yes and no. 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.
    - eliasmacpherson 4y ago
      Helper functions, PIMPL, that's all fine - the declaration and function body of the template is still defined in the .hpp. Whether all of the body of the template is also defined there was not my concern in asking. Thanks for your comment. I will have to dig in to modules in due course.
linkdd 4y ago
The lack of C or C++ build system makes me prefer header-only libraries, like nlohmann/json, entt, etc... I do also like easily embeddable tech like imgui, or lua, where you can simply copy the source code in your source tree.
- pjmlp 4y ago
  If anything there are plenty of options. How come we have managed during the last 40 years?
  - linkdd 4y ago
    I should have said: the lack of standardized build system. CMake is a pain, Bazel, vcpkg, autotools, plain old Makefiles, etc... All of them do not match the developer experience of npm, cargo, etc... 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.
    - pjmlp 4y ago
      You should have installed it already via the OS package system, or the modern alternative, conan/vcpkg.
  - flohofwoe 4y ago
    It was a massive pain in the butt in that time. Just try to intregrate a "standard library" like libjpeg or libpng into your cross-platform project. That's exactly why everybody has switched over to stb_image.h to quickly load image data without hassle.
    - pjmlp 4y ago
      Easy, have your "load/save_image" calls the OS provided APIs for image handling, while on UNIX assume the libjpeg-dev or libpng-dev are already installed via the OS package system, have the makefile targets adjusted as needed per platform. Nowadays, use cmake + conan/vcpkg as alternative as well. Do we need to spoon-feed everything?
flohofwoe 4y ago
The most popular "header only" (or rather "single file" libs) are mostly written in C though: https://github.com/nothings/stb 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).

matheusmoreira 4y ago

> "header only libraries": they're nontrivial to bind to from non-C languages. Why? Can't you make a shared object just as easily?

linkdd 4y ago

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.

FeepingCreature 4y ago
I still need to parse the header. For 90% of libraries you can just parse the subset of C that's required for function declarations.
- linkdd 4y ago
  https://github.com/eliben/pycparser https://github.com/eliben/pycparser

flohofwoe 4y ago

> they're nontrivial to bind to from non-C languages 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-zig - https://github.com/floooh/sokol-nim https://github.com/floooh/sokol-nim - https://github.com/floooh/sokol-odin https://github.com/floooh/sokol-odin These are all auto-generated from STB-style single-file libraries: https://github.com/floooh/sokol https://github.com/floooh/sokol

FeepingCreature 4y ago
Oh yeah that'd do it. Good point.