4 ms·

There are lots of problems with single-file libraries. Here are a few but I'm sure there are others I've forgotten or haven't thought of. * You have to wait fo

There are lots of problems with single-file libraries. Here are a few but I'm sure there are others I've forgotten or haven't thought of. * You have to wait for compilation of the whole library at least once every time you do a build of your program - certainly every time you do a clean build, and potentially even incremental builds if it's header only. * If the library is header only (many of the linked libraries are) then you you potentially have to pay that compilation cost more than once per compilation of your program - once per every one of your source files that include it. * Again this is specific to header-only libraries, but to avoid code bloat you'll need to turn on link-time optimisation which is far slower than just allowing the linker to do its job by only compiling definitions into a single object file. (Admittedly LTO is a good idea anyway, but adding a bunch of duplicated symbols is avoidable extra work for it.) * Some useful libraries are realistically just too big for their authors to write the whole thing in one file (e.g. protobuf, opencv, ... in fact most libraries I use on a regular basis seem to fall into that). They could "release" the library in single-file format, similar to SQLite's amalgam, but then if there are any problems (either a bug in their code or something in your code that makes you want to look at their code) you're now not looking at the original source but some mangled version of it. * If the library is so large that its interface needs to be split over multiple headers (think Boost or OpenCV) then you're now bang out of luck. Hopefully the library has cleanly-enough separated modules you could potentially release these separately (e.g. OpenCV core, imgproc, imgcodecs, highgui, ...) but then you're essentially back to multi-file libraries. * Adding a library with a lot of its own transitive depedencies takes proportionally the amount of effort as the number of those dependencies, rather than being handled automatically. One interesting thing about all of these problems is that they get worse and worse as you need more libraries in your program, or need a larger library for your program. In contrast, using a package manager (I'm thinking particularly vcpkg here) tends to add a one-time cost at the start but allows you to scale your dependency list almost for free. If you're writing your own library, rather than a application, then there are even more problems with this approach, but I won't quite open that can of worms.

CyberDildonics 6y ago
Compilation time realistically is not a big problem. Managing compilation units by grouping up what changes infrequently actually make compilation faster in general and much faster incrementally. Even visual studio's compiler compiles sqlite's 6MB in under a second. > Again this is specific to header-only libraries, but to avoid code bloat you'll need to turn on link-time optimisation This is nonsense. This list seems like you are trying to invent problems that aren't there. The vast majority of the time you decide what compilation unit to put the definitions into and that's it.
- quietbritishjim 6y ago
  > Compilation time realistically is not a big problem. ... sqlite's 6MB in under a second SQLite is notably pure C, which compiles orders of magnitude faster than C++, or at least certain types of C++. I've worked on a project - not particularly large - where using precompiled headers reduced compilation time from something like an hour and a half to more like 15 minutes. Admittedly that's a very old crusty laptop, but that's without building the libraries, which are compiled separately! Even on much faster modern machines, building the dependencies is at least an hour, maybe more. I wonder if our opinions are so strongly at odds because we're simply working in totally different situations to start with. As I hope I've illustrated, compilation time definitely IS an issue for us, but obviously it's not for the projects you're working on - which must surely be C-based or at least C-like C++ code. I would wager more people are in my situation, but to some extent that's irrelevant. The advice to other devs has to be: if you're happy to restrict yourself to small C or C-like libraries then single file libraries are fine, but if you want to take advantage of the full C++ ecosystem be aware that there package managers (again, I'm mainly thinking vcpkg) you can use with only a little initial effort. I think it's dangerous for beginners to see articles like the one linked to here in case it makes them think that using C++ has to be like that. > > Again this is specific to header-only libraries, but to avoid code bloat you'll need to turn on link-time optimisation > This is nonsense. ... The vast majority of the time you decide what compilation unit to put the definitions into and that's it. I said that this paricular objection obly applies to header-only libraries, and that qualification is even in the bit you quoted. I never claimed that there are no single-file libraries that allow separate compilation. But I do dispute that the "vast majority" allow or require separate compilation (either as a separately supplied .c/.cpp file, or by #defining something before one of the uses of the header). That is the exact opposite of my experience. As an experiment I looked at all the libraries listed under "argv" in the linked article, and 9 of them were header only with no option for separate compilation (Argh!, Clara, CLI11, cmdline, flags, kgflags, linkom, optionparser, ProgramOptions.hxx) while only 1 (parg) allowed separate compilation.
attractivechaos 6y ago
The owner of the repo writes many single-file libraries in C. Apparently you are not familiar with his coding style; otherwise you wouldn't have these complaints on linking. For his (and many others') libraries, you "instantiate" the implementation in a .c file and declare functions in other source files. This way you only compile the library implementation once. In addition, although the name of the repo is "single_file_libs", it links to many double-file libraries consisting of a pair of .c and .h files. These libraries won't have the issues you are talking about. Developers are well aware of the potential linking problems. That said, you are right that single/double-file libraries tend to be small. It is hard to work with a file with >10,000 LOCs anyway.
- quietbritishjim 6y ago
  > The owner of the repo writes many single-file libraries in C. Apparently you are not familiar with his coding style; otherwise you wouldn't have these complaints on linking. I never claimed to be writing only about his libraries, but instead about single-file libraries in general. Sorry if I wasn't clear about that. > For his (and many others') libraries, you "instantiate" the implementation in a .c file and declare functions in other source files. This way you only compile the library implementation once. I tried to make clear which of the bullet points only applied to header-only libraries (again, apologies if it wasn't clear). For example, my objection to compiling the same library multiple times specifically applied only header only libraries. As you say, with two-file (or single .c file, if you like) libraries you only have to compile the library once per build of your program - but as I made clear in a separate point, that is still potentially a pain if you do a clean build (but it could be mitigated by having a separate CMake target, or whatever, that contains all your library files). > In addition, although the name of the repo is "single_file_libs", it links to many double-file libraries consisting of a pair of .c and .h files. These libraries won't have the issues you are talking about. Developers are well aware of the potential linking problems. As I just said, I had tried to distinguish those cases. They're less problematic, but still somewhat problematic. > That said, you are right that single/double-file libraries tend to be small. It is hard to work with a file with >10,000 LOCs anyway. Yes, and if you only need a small number of small libraries then all my objections are a lot less severe. To spin the conclusion on its head - you can avoid going down the package manager route if you avoid having any large dependencies. For some projects that's acceptable. Personally, I find the pain of working without basic largish libraries like protobuf to be enormous compared to the relatively simple process of using a package manager.

CyberDildonics 6y ago

Compilation time realistically is not a big problem. Managing compilation units by grouping up what changes infrequently actually make compilation faster in general and much faster incrementally. Even visual studio's compiler compiles sqlite's 6MB in under a second. > Again this is specific to header-only libraries, but to avoid code bloat you'll need to turn on link-time optimisation This is nonsense. This list seems like you are trying to invent problems that aren't there. The vast majority of the time you decide what compilation unit to put the definitions into and that's it.

quietbritishjim 6y ago
> Compilation time realistically is not a big problem. ... sqlite's 6MB in under a second SQLite is notably pure C, which compiles orders of magnitude faster than C++, or at least certain types of C++. I've worked on a project - not particularly large - where using precompiled headers reduced compilation time from something like an hour and a half to more like 15 minutes. Admittedly that's a very old crusty laptop, but that's without building the libraries, which are compiled separately! Even on much faster modern machines, building the dependencies is at least an hour, maybe more. I wonder if our opinions are so strongly at odds because we're simply working in totally different situations to start with. As I hope I've illustrated, compilation time definitely IS an issue for us, but obviously it's not for the projects you're working on - which must surely be C-based or at least C-like C++ code. I would wager more people are in my situation, but to some extent that's irrelevant. The advice to other devs has to be: if you're happy to restrict yourself to small C or C-like libraries then single file libraries are fine, but if you want to take advantage of the full C++ ecosystem be aware that there package managers (again, I'm mainly thinking vcpkg) you can use with only a little initial effort. I think it's dangerous for beginners to see articles like the one linked to here in case it makes them think that using C++ has to be like that. > > Again this is specific to header-only libraries, but to avoid code bloat you'll need to turn on link-time optimisation > This is nonsense. ... The vast majority of the time you decide what compilation unit to put the definitions into and that's it. I said that this paricular objection obly applies to header-only libraries, and that qualification is even in the bit you quoted. I never claimed that there are no single-file libraries that allow separate compilation. But I do dispute that the "vast majority" allow or require separate compilation (either as a separately supplied .c/.cpp file, or by #defining something before one of the uses of the header). That is the exact opposite of my experience. As an experiment I looked at all the libraries listed under "argv" in the linked article, and 9 of them were header only with no option for separate compilation (Argh!, Clara, CLI11, cmdline, flags, kgflags, linkom, optionparser, ProgramOptions.hxx) while only 1 (parg) allowed separate compilation.

attractivechaos 6y ago

The owner of the repo writes many single-file libraries in C. Apparently you are not familiar with his coding style; otherwise you wouldn't have these complaints on linking. For his (and many others') libraries, you "instantiate" the implementation in a .c file and declare functions in other source files. This way you only compile the library implementation once. In addition, although the name of the repo is "single_file_libs", it links to many double-file libraries consisting of a pair of .c and .h files. These libraries won't have the issues you are talking about. Developers are well aware of the potential linking problems. That said, you are right that single/double-file libraries tend to be small. It is hard to work with a file with >10,000 LOCs anyway.

quietbritishjim 6y ago
> The owner of the repo writes many single-file libraries in C. Apparently you are not familiar with his coding style; otherwise you wouldn't have these complaints on linking. I never claimed to be writing only about his libraries, but instead about single-file libraries in general. Sorry if I wasn't clear about that. > For his (and many others') libraries, you "instantiate" the implementation in a .c file and declare functions in other source files. This way you only compile the library implementation once. I tried to make clear which of the bullet points only applied to header-only libraries (again, apologies if it wasn't clear). For example, my objection to compiling the same library multiple times specifically applied only header only libraries. As you say, with two-file (or single .c file, if you like) libraries you only have to compile the library once per build of your program - but as I made clear in a separate point, that is still potentially a pain if you do a clean build (but it could be mitigated by having a separate CMake target, or whatever, that contains all your library files). > In addition, although the name of the repo is "single_file_libs", it links to many double-file libraries consisting of a pair of .c and .h files. These libraries won't have the issues you are talking about. Developers are well aware of the potential linking problems. As I just said, I had tried to distinguish those cases. They're less problematic, but still somewhat problematic. > That said, you are right that single/double-file libraries tend to be small. It is hard to work with a file with >10,000 LOCs anyway. Yes, and if you only need a small number of small libraries then all my objections are a lot less severe. To spin the conclusion on its head - you can avoid going down the package manager route if you avoid having any large dependencies. For some projects that's acceptable. Personally, I find the pain of working without basic largish libraries like protobuf to be enormous compared to the relatively simple process of using a package manager.