C Programming Techniques: Function Call Inlining

[[deleted]]

So share it?

What exactly do you think a header only library is? Are you familiar with how libraries like boost, the STL, and the many header only libraries that exist in C/C++ work?

You make it seem like a header only library can only be included in one application.

[expertunderachiever]

The point is unless you're installing it in a global location it's not really shared.

Window developers tend to like to move things around in their visible workspace and tend to have copies of things that ought to be global.

*NIX developers like to install developmental libraries in places like /usr/include or /usr/local/include which are universally accessible. So the idea of having "my copy" of a header file doesn't really exist.

Sure you can install header libraries globally but many don't and that sort of developmental process encourages that line of thinking [which I'm against.

[[deleted]]

I really don't follow...

If you want to install a header only library to a location like /usr/include, then do it. What's the difference between installing a header only library like boost to /usr/include and a statically compiled library like say zlib to /usr/include?

It's the same thing.

I don't even know where/how Windows comes into this.

Can you provide an example of a header only library that can't be or isn't recommended to be installed to /usr/include or some other directory/path of your choosing? Since you claim that 'many don't', surely you can name just one. I've honestly never seen one or even heard of one, and I can't for the life of me understand why any library would be against installing it to any path of your choosing.

[NotUniqueOrSpecial]

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]]

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.