7 ms·

Forcing me to define `XXX_IMPL` in a single compilation unit is not a header-only library. It will simply force me to make a `.c` file for every `.h` and defin

by linkdd 4y ago

Forcing me to define `XXX_IMPL` in a single compilation unit is not a header-only library. It will simply force me to make a `.c` file for every `.h` and define it there. Why not simply distribute the .c/.h like imgui does, or lua, or many many others? I'm already copy/pasting your .h files, I would not mind copy/pasting .c files and adding them to my build system, since that's what I'm gonna do anyway to make sure i do not define `XXX_IMPL` multiple times. Header-only libraries truly only work in C++ when it's all templates anyway.

Asooka 4y ago
And even if you want to do some kind of single-object build for your utility libraries to speed up linking, you can always include the .c file in some big master .c file.
- pjmlp 4y ago
  Back in the day we would use libraries, but what do I know.
badsectoracula 4y ago
> It will simply force me to make a `.c` file for every `.h` and define it there. You can do that of course but you'd be missing the point of how it is meant to be used. Your project already has at least a single .c file anyway, so why make a separate .c file just so you can put `XXX_IMPL` in there instead of putting it in the .c file that is going to be using the library itself?
- linkdd 4y ago
  Because: - I like my object files (.o) to only contain what they are supposed to contain and nothing else - I don't want to have to keep track of where did I put the `XXX_IMPL` No I'm not missing the point of how it is meant to be used, I'm criticizing that use case as a very poor one, I'd even say it's an anti-pattern IMHO.
  - badsectoracula 4y ago
    Right, but those would be your choices, it wouldn't be the library itself forcing you to do that, it would be your personal preferences. That isn't a fault of the library.
    - linkdd 4y ago
      By not making a choice, the library is actually making the worst possible decision. It is bloating my ABI if I'm not careful, and it makes distributing more cumbersome when it could/should be straightforward. That's just not how you are supposed to distribute a C library, this is a poor design that clearly states "I don't know or don't care how to package my code".
      - badsectoracula 4y ago
        The library did make a choice - header-only C libraries are a choice. And the "how you are supposed to distribute a C library" is clearly just your own opinion you are trying to pass as objective truth. There are many header-only C libraries out there written by many experienced programmers that contradict your opinions. TBH this is really just bikeshedding, not real issues. IMO even a tab-vs-spaces argument would have more merit as that has real practical effects (appearance of the code in tools like terminal or sites that have forced tabs like code review sites or github).
        linkdd 4y ago
        There are billions of flies who eat shit. Therefore, shit should be edible? The "numbers argument" is a fallacious one. No, "how you are supposed to distribute a C library" is not my opinion, but the experience/observations of the last 50 years of engineering. Why would we even have a .so/.a/.lib/.dll format for libraries? As I said in a sibling comment, those are not header-only libraries. It's poorly packaged .c/.h in a single file that we happened to name with the .h extension. It's not a header, it's a header+implementation. And it's bad practice, and any decent C developer will tell you so.
      - 4y ago
- ranger_danger 4y ago
  Making a separate C file prevents you from having to recompile the single-header lib every time a change is made to the file with the IMPL in it. Also compilation of a single file is a lot worse when it's really big, compared to several smaller files that can use multiple cores.
flohofwoe 4y ago
Well, everything is in a header, so 'header only' is sorta correct - but the name is also problematic because that's what 'header only' C++ libraries (with the implementation in inline methods) are often called too, and those do actually suffer from downsides, such as increased compilation time. A more correct name is 'STB-style single-file libraries' and it's really just a distribution format, nothing to get all worked up about - the differences to a single .h/.c pair are mostly negligible. A common way to integrate such libraries into a non-trivial project is not to create one .c file for each header, but instead to create one .c file for a whole group of related headers (up to all external single-file dependencies of a project in a single implementation file), this may actually decrease compilation time the same way that unity/jumbo builds do, and since external dependencies don't change, this is also not a problem for incremental builds. Another advantage: at least the original STB libraries (stb_image.h etc...) are often used in small command line tools, those can simply include the implementation in the "main.c" source, resulting in a project with dependencies that's still compiled as a single source file: cc -O3 mytool.c -o mytool ...e.g. no build system needed at all.

by linkdd 4y ago

Asooka 4y ago

And even if you want to do some kind of single-object build for your utility libraries to speed up linking, you can always include the .c file in some big master .c file.

pjmlp 4y ago
Back in the day we would use libraries, but what do I know.

badsectoracula 4y ago

> It will simply force me to make a `.c` file for every `.h` and define it there. You can do that of course but you'd be missing the point of how it is meant to be used. Your project already has at least a single .c file anyway, so why make a separate .c file just so you can put `XXX_IMPL` in there instead of putting it in the .c file that is going to be using the library itself?

linkdd 4y ago
Because: - I like my object files (.o) to only contain what they are supposed to contain and nothing else - I don't want to have to keep track of where did I put the `XXX_IMPL` No I'm not missing the point of how it is meant to be used, I'm criticizing that use case as a very poor one, I'd even say it's an anti-pattern IMHO.
- badsectoracula 4y ago
  Right, but those would be your choices, it wouldn't be the library itself forcing you to do that, it would be your personal preferences. That isn't a fault of the library.
  - linkdd 4y ago
    By not making a choice, the library is actually making the worst possible decision. It is bloating my ABI if I'm not careful, and it makes distributing more cumbersome when it could/should be straightforward. That's just not how you are supposed to distribute a C library, this is a poor design that clearly states "I don't know or don't care how to package my code".
    - badsectoracula 4y ago
      The library did make a choice - header-only C libraries are a choice. And the "how you are supposed to distribute a C library" is clearly just your own opinion you are trying to pass as objective truth. There are many header-only C libraries out there written by many experienced programmers that contradict your opinions. TBH this is really just bikeshedding, not real issues. IMO even a tab-vs-spaces argument would have more merit as that has real practical effects (appearance of the code in tools like terminal or sites that have forced tabs like code review sites or github).
      - linkdd 4y ago
        There are billions of flies who eat shit. Therefore, shit should be edible? The "numbers argument" is a fallacious one. No, "how you are supposed to distribute a C library" is not my opinion, but the experience/observations of the last 50 years of engineering. Why would we even have a .so/.a/.lib/.dll format for libraries? As I said in a sibling comment, those are not header-only libraries. It's poorly packaged .c/.h in a single file that we happened to name with the .h extension. It's not a header, it's a header+implementation. And it's bad practice, and any decent C developer will tell you so.
    - 4y ago
ranger_danger 4y ago
Making a separate C file prevents you from having to recompile the single-header lib every time a change is made to the file with the IMPL in it. Also compilation of a single file is a lot worse when it's really big, compared to several smaller files that can use multiple cores.

flohofwoe 4y ago

Well, everything is in a header, so 'header only' is sorta correct - but the name is also problematic because that's what 'header only' C++ libraries (with the implementation in inline methods) are often called too, and those do actually suffer from downsides, such as increased compilation time. A more correct name is 'STB-style single-file libraries' and it's really just a distribution format, nothing to get all worked up about - the differences to a single .h/.c pair are mostly negligible. A common way to integrate such libraries into a non-trivial project is not to create one .c file for each header, but instead to create one .c file for a whole group of related headers (up to all external single-file dependencies of a project in a single implementation file), this may actually decrease compilation time the same way that unity/jumbo builds do, and since external dependencies don't change, this is also not a problem for incremental builds. Another advantage: at least the original STB libraries (stb_image.h etc...) are often used in small command line tools, those can simply include the implementation in the "main.c" source, resulting in a project with dependencies that's still compiled as a single source file: cc -O3 mytool.c -o mytool ...e.g. no build system needed at all.