4 ms·

>> Single header libraries are hugely more ergonomic and easy to use. Just get the file, #include it and you're done! Most C libraries on GitHub prefer this mod

>> Single header libraries are hugely more ergonomic and easy to use. Just get the file, #include it and you're done! Most C libraries on GitHub prefer this mode of distribution now I find that odd. How is that significantly better than dropping 2 files into a project and #including the header? A good build system should just compile all the C or C++ files in a given place, so nothing needs to be changed other than dropping the files in and #include where called from.

rytill 5y ago
Why use two files instead of one?
- bluedino 5y ago
  What if you want to use the functions in other C files? What if you want to compile them all separately?
  - hn_acc_2 5y ago
    1) Include it wherever it's used. The convention is to use the preprocessor[1] so it only appears once in the final binary 2) Most developers just want to compile to a single binary. Any developer who for some reason needs separately compiled objects should be able to quickly achieve that from a single-file library [1] https://github.com/phoboslab/qoi/blob/324c2243b2fb35f741a88d73ae10c132ccbba0b1/qoi.h#L158-L159 https://github.com/phoboslab/qoi/blob/324c2243b2fb35f741a88d...
hn_acc_2 5y ago
The difference will be painfully clear once you try to walk a junior developer through installing and linking new files to a large project in Visual Studio, vs "copy this .h file here and include it". Whether or not a "good build system" should handle it, the fact that single-file libraries are much preferred these days should demonstrate most people don't have such a build system
- 10000truths 5y ago
  So much of the C/C++ ecosystem revolves around knowing your build tools that, for most intents and purposes, it should honestly be considered an integral part of the languages. If I ever teach an introductory C/C++ course, I would dedicate at least 1/4 of my time to explaining: * What a translation unit is, and how compiling a translation unit to an object file works * What a linker is, and how the linker combines object files into a library/executable * What make/autotools/cmake are, and how they work * What FHS is, and how it standardizes the lib/bin/include paths that C/C++ build tools read from/install to And so on. Any C/C++ course that goes beyond a “Hello world” program without explaining these concepts in detail does its students a disservice.
  - BlueTemplar 5y ago
    Yeah, in our class we had to figure out this mostly on our own, so after it I'm still at the level where I barely manage to make make work, I'll have to look into those other ones, thanks !
michael-ax 5y ago
its not 'significantly better'. but also ask "why are the tables of content prefixing the contents of all my books?" its taken ages, but with this model, c lib authoring has finally taken something that was a core strength of pascal: single-file modularity. though in theory there's no difference between theory and practice, in practice, there is. and this kind of packaging makes a lot of sense for a lib like this.

rytill 5y ago

Why use two files instead of one?

bluedino 5y ago
What if you want to use the functions in other C files? What if you want to compile them all separately?
- hn_acc_2 5y ago
  1) Include it wherever it's used. The convention is to use the preprocessor[1] so it only appears once in the final binary 2) Most developers just want to compile to a single binary. Any developer who for some reason needs separately compiled objects should be able to quickly achieve that from a single-file library [1] https://github.com/phoboslab/qoi/blob/324c2243b2fb35f741a88d73ae10c132ccbba0b1/qoi.h#L158-L159 https://github.com/phoboslab/qoi/blob/324c2243b2fb35f741a88d...

hn_acc_2 5y ago

The difference will be painfully clear once you try to walk a junior developer through installing and linking new files to a large project in Visual Studio, vs "copy this .h file here and include it". Whether or not a "good build system" should handle it, the fact that single-file libraries are much preferred these days should demonstrate most people don't have such a build system

10000truths 5y ago
So much of the C/C++ ecosystem revolves around knowing your build tools that, for most intents and purposes, it should honestly be considered an integral part of the languages. If I ever teach an introductory C/C++ course, I would dedicate at least 1/4 of my time to explaining: * What a translation unit is, and how compiling a translation unit to an object file works * What a linker is, and how the linker combines object files into a library/executable * What make/autotools/cmake are, and how they work * What FHS is, and how it standardizes the lib/bin/include paths that C/C++ build tools read from/install to And so on. Any C/C++ course that goes beyond a “Hello world” program without explaining these concepts in detail does its students a disservice.
- BlueTemplar 5y ago
  Yeah, in our class we had to figure out this mostly on our own, so after it I'm still at the level where I barely manage to make make work, I'll have to look into those other ones, thanks !

michael-ax 5y ago

its not 'significantly better'. but also ask "why are the tables of content prefixing the contents of all my books?" its taken ages, but with this model, c lib authoring has finally taken something that was a core strength of pascal: single-file modularity. though in theory there's no difference between theory and practice, in practice, there is. and this kind of packaging makes a lot of sense for a lib like this.