If you're using C++, you want speed and/or memory efficiency. Generic libraries won't give you that. You need custom implementations of data structures that make the trade-offs relevant to your needs.
As an example, look at this folder which:
https://github.com/facebook/folly/tree/master/folly/compress...
In short, these are compression tools. Why not have 1 easily uninstallable package per compression tool in a standard package manager that works the same on all platforms.
Things don't have to be more or less generic.
This is more of an artifact of companies that produced them, which use large monorepos, than the ecosystem itself.
That said, you can pick and choose which part of boost you use, just as you can pick and choose which part of Abseil/Folly you use.
Because C++ sucks and its dependency story is a nightmare. There are a few competing C++ package managers. They’re all relatively new and none of them are particularly popular.
The most widespread C++ libraries are ones that are single header files. Because that’s the only thing that’s trivial to implement into an existing project.
Compiling OpenSSL requires installing Strawberry Perl. This type of garbage of BS is the norm.
Source: C++ dev for 15 years
I think this has much more to do with templates than anything else. A template can only exist in a header.
Then there is also the performance benefit of inlining. (As well as performance hit of inlining, namely code size.)
There is a separate, much later movement/phenomenon of C (not C++) developed as header-only libraries, which by contrast I don't think there is nearly as good reason for except for that some people are confused at how a linker works. I have seen use of that technique advocated on Hacker News much more frequently than in production.
These libraries generally have no third party dependencies. Because tracking down and compiling C++ dependencies is a dumpster fire.
I would take the sqlite amalgamation as an example of good use of "few files, few dependencies". First off, it is above all a solid piece of work. It is distributed with one header file and one .c, even though it is developed as multiple files. Iirc the sqlite website cites a ~10% speed improvement or so due to the optimizer being able to do a better job across the whole library. In my opinion this is a better reason than "tracking dependencies sucks" or "omg too many files".
The presence of a defacto package manager completely changes the library dynamics.
I can't even link and test properly against GMP on Windows :/
It also predates the time period when people would whine about a lack of package managers.
As do a bunch of these libraries.
The standard libraries should, in that they can have Spooky Deep Knowledge of the compiler and other standard libraries which external code won't, like how there's no way to add two ints which is faster than the standard + operator.
A simple example is `std::vector`. The structure is a nice resizable array, but for a long time you couldn't override the allocator and the performance of your application could be affected by heap fragmentation or even just the performance cost of heap allocations. A lot of C++ shops often wrote their own replacement containers that had a better allocation strategy. The design needs of a PlayStation 2 programmer ended up being different than an x86 desktop computer with virtual memory.