3 ms·

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

• tredre3 2y ago
  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"
• colleagueRiley 2y ago
  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.
  • uecker 2y ago
    I am not say it is hard. But I find having a .c/.h pair more useful and easier to work with.
    • colleagueRiley 2y ago
      No lol
      • uecker 2y ago
        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"