Daniela Engert wrote:
Is Boost - a framework? This means Boost.x uses facilities from Boost.y even when there is a viable alternative in the standard library (or a non-Boost library with the same API), but rather insists on the Boost.y dependency. - a polyfill? This means Boost.x strives to depend on standard library facilities as much as possible - at least as configuration option. - a loose collection of libraries that share a common moniker? This means that every library developer does what they see fit according to their assessment of the state of the ecosystem. - a showcase of avantgarde, high-quality C++ building blocks that every developer is proud to use, and can look at to learn about good C++ for their own advancement?
All of the above. (1) It's not possible to use a standard library feature introduced in e.g. C++17 in a Boost library that supports e.g. C++14, and "a configuration option" doesn't work well for reasons already explained numerous times here. In addition to that, sometimes Boost components offer additional functionality over the standard ones, so libraries can prefer them even when the previous sentence doesn't apply. This is not particularly unique in the C++ world - every code base does it. (2) Boost.Compat is a "polyfill", but Boost as a whole obviously not. What does Boost.JSON "polyfill"? (3) Yes, this has always been the case. (4) Yes, although this wasn't a requirement in the "original Boost". But first and foremost, Boost is a mechanism by which we, volunteer C++ developers, provide value to the C++ community. This has more than one aspect; Boost provides well designed and tested libraries that have good platform coverage, but Boost also "comes preinstalled" for many, avoiding the need to separately bring in disparate C++ dependencies.