Well, I do not use them at all. But I agree that this mechanism would avoid the additional copies. I have seen other single-header libraries though...

In any case, forcing me to figure out the specific XYZ_IMPLEMENTATION for each library is less user friendly that just proving a .c and .h file.

I actually agree with you that single-header libs are often not ideal. They're kind of neat in concept: just copy paste and done!

But after being burned a few times by naming or linking conflicts or you cloned your .c and forgot to remove the #define and now you have two implementations or having to debug any BSS/DATA/TEXT issues (because now lib and user code end up in the same .o and the linker can't do its magic for your esoteric architecture), I just took the habit of always manually creating a matching .c that only contains:

    #define BLAH_IMPLEMENTATION
    #include "blah.h"

Well for one you're able to easily use macros to customize features you want and don't want. Plus "forcing me to figure out the specific XYZ_IMPLEMENTATION" is a big of a weird compliant. You could say the same thing about linking a library. Besides, it's not hard to figure out and is usually one of the first lines of the file.

The single-header format also gives you MORE ways to compile the library and control which features to use or not use.

I am not say it is hard. But I find having a .c/.h pair more useful and easier to work with.

No lol

Because looking up a macro name for each library is easier than adding a c file to your makefile? You could still always do

  #include "impl.c"

and this would still be nicer than

  #define XZUGG_IMPL
  #include "impl.h"