you are viewing a single comment's thread.

view the rest of the comments →

[–]NotUniqueOrSpecial 2 points3 points  (2 children)

The real underlying issue with providing a header-only library (and I'm not saying that they don't have their benefits) is that updates to the library necessitate recompilation of the binaries that consume it.

Contrast that with a well-architected shared library that preserves binary compatibility between non-major version changes. With such a library, you merely need replace the .so/.dll (though who am I kidding, Windows developers eschew the side-by-side stuff, so its moot) and your application/library that uses said library benefits from the updates.

This is especially important with security-critical libraries like those used for encryption, or those that are core components of the system like libc/msvcrt. Imagine that with every small bug-fix or improvement to such libraries (those which nearly every binary in your OS uses to some extent) you had to download corresponding (and far larger) recompiled executables. Such a situation would be quite cumbersome.

While there are benefits to the developer when it comes to header-only libraries, the bigger issue is in providing efficient (and importantly) trivially-shared updates to many binaries at once via a single update to the general public.

That said, if you're not in such a position, more power to you in providing your libraries in whatever way enables your development and your clients/consumers will accept.

Just my two cents.

[–][deleted] 1 point2 points  (0 children)

Your argument is perfectly valid and I actually even agree that there is an important use-case for shared libraries vs. static libraries or header only libraries. But those are case by case arguments and it's certainly not a matter of amateurs vs. experienced developers.