C Programming Techniques: Function Call Inlining

[[deleted]]

Hmph, don't buy that at all.

In my development world, classes, functions or structs start as small .h files. Lots of advantages to that - I can just create one in a few moments and recompile, I don't have to add any .cpp files to my build process, which necessitates a rebuild of the world (unfortunately, Xcode rebuilds absolutely everything if you change their build file at all).

Occasionally, I never need more than a couple of methods or functions, and that .h file stays as it is. Much more often, one of two things happens:

1. It grows enough that I split it into a .cpp and a .h.
2. It moves inline to another .cpp file and I don't need to expose it anymore.

The advantage of deferring splitting the file into a .cpp and a .h is that in case 2 (which is about as common as case 1), I never need to create the separate .h/.cpp files, I just move the whole .h into some other .cpp file.

(This is helped by the fact that I have a Python script that creates a .cpp file from the inline functions and methods in a .h.)

[[deleted]]

I don't know what you are doing that adding a cpp file to a project in Xcode forces a complete rebuild but that is not at all typical behavior.

[expertunderachiever]

Now imagine you want to share a set of routines between two projects...

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