3 ms·

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

> 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.
    - stelonix 4y ago
      There really is no "correct way" to distribute C libraries and at this point it seems you're nitpicking just to nitpick. Imgui uses the same method, no one ever complained. If you do require obj files to not be "bloated" (why?) you can always do it the C way of having separate C/H files.
      - linkdd 4y ago
        imgui distribute .c/.h files, not .h files with .c embedded in them. What I'm criticizing is the extra step of me having to write the .c files anyway to avoid bloating the obj files, which should have been done by the library in the first place.
        torstenvl 4y ago
        As others have pointed out, you don't need to write extra .c files, and you won't bloat the obj files. This paradigm is fairly common, see, e.g.: https://github.com/lieff/minimp3 https://github.com/lieff/minimp3 https://github.com/Immediate-Mode-UI/Nuklear https://github.com/Immediate-Mode-UI/Nuklear https://github.com/mattiasgustavsson/libs/blob/main/docs/http.md https://github.com/mattiasgustavsson/libs/blob/main/docs/htt...
      - pjmlp 4y ago
        There is, just like C has been doing in its 50 years of history, header only libraries are a consequence of new generations pretending C is something like Python.
    - flohofwoe 4y ago
      > It is bloating my ABI if I'm not careful How so? The private implementation functions are usually declared static, only the public API functions are visible to the linker. Some single-file libraries also allow to declare the entire API as static (via a config define) so that none of the library API functions are visible to the linker.
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.

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.
  - stelonix 4y ago
    There really is no "correct way" to distribute C libraries and at this point it seems you're nitpicking just to nitpick. Imgui uses the same method, no one ever complained. If you do require obj files to not be "bloated" (why?) you can always do it the C way of having separate C/H files.
    - linkdd 4y ago
      imgui distribute .c/.h files, not .h files with .c embedded in them. What I'm criticizing is the extra step of me having to write the .c files anyway to avoid bloating the obj files, which should have been done by the library in the first place.
      - torstenvl 4y ago
        As others have pointed out, you don't need to write extra .c files, and you won't bloat the obj files. This paradigm is fairly common, see, e.g.: https://github.com/lieff/minimp3 https://github.com/lieff/minimp3 https://github.com/Immediate-Mode-UI/Nuklear https://github.com/Immediate-Mode-UI/Nuklear https://github.com/mattiasgustavsson/libs/blob/main/docs/http.md https://github.com/mattiasgustavsson/libs/blob/main/docs/htt...
    - pjmlp 4y ago
      There is, just like C has been doing in its 50 years of history, header only libraries are a consequence of new generations pretending C is something like Python.
  - flohofwoe 4y ago
    > It is bloating my ABI if I'm not careful How so? The private implementation functions are usually declared static, only the public API functions are visible to the linker. Some single-file libraries also allow to declare the entire API as static (via a config define) so that none of the library API functions are visible to the linker.

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.