4 ms·

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 cu

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

by linkdd 4y ago

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.