Hacker News Reader

Comment by kevin_thibedeau | Hacker News Reader

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

The most popular "header only" (or rather "single file" libs) are mostly written in C though:

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).

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.

If anything there are plenty of options.

How come we have managed during the last 40 years?

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.

You should have installed it already via the OS package system, or the modern alternative, conan/vcpkg.

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.

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?

...and with all this you just made everything a thousand times harder (and more brittle) than it needs to be. Integrating stb_image.h is literally just a single #include statement, no matter the platform, build system or dependency manager (if any).

Other than having someone keep track of it, across all projects it gets included, even if it gets vendored somewhere there is the issue with symbol duplication across binary libraries used across teams.

Also it is a toy library in size, then there are those that can be used to stress test compilers.

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.

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?

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.

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.

Reply on news.ycombinator.com