Am 27.03.2024 um 14:47 schrieb Vinnie Falco via Boost:
I guess I'm confused. My understanding is that libraries are considered good candidates for the Boost collection based on meeting some or all of certain criteria:
* They offer useful, novel functionality not found elsewhere * The API is superior to other libraries that do similar things * The implementation is exceptionally performant * Solving a familiar problem in a particularly elegant fashion * The library is already popular and has field experience * The library offers C++ standard functionality for older compilers
That's a diverse collection of criteria that may or may not guide adoption of new libraries into Boost. As a long-term user, contributor, and maintainer of our in-house flavour of Boost, I want to share *my* point of view to answer your question. In my opinion, Boost is lacking a vision (the original one doesn't seem to be alive anymore). 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? If it's the first, then be clear about that. And tell prospective users that they should expect huge Boost dependency chains. My teammates get *all* of Boost from our in-house distribution because that's where they end up anyway to some degree if they decide to take advantage of one the heavy-weight libraries. If it's the second then the question about the minimum supported C++ standard or compiler toolset becomes moot. But then you have to think hard about the adoption of ne libraries because you most likely want to backport them. And each individual library needs to provide configuration options to let go other Boost libraries if the consumer decides so (like std::variant instead of boost::variant, std::shared_ptr instead of boost::shared_ptr, vanilla Asio instead of boost::asio). If the user rather accepts performance hits by using standard facilities over alledgedly superiour Boost alternatives, that's fine. Every additional dependency has a cost, most certainly in compile times. If it's the third, then you may keep the status-quo. Everything goes. Consumers need to assess if a certain Boost library is worth the efforts to depend on over the projected course of their project. If it's the last option, go for it! Don't accept "me too" libraries. Require recent toolsets. Require the current language standard. Show what you can do with contemporary C++. The bar for adoption needs to be high. When I look at the projects in the company that I work, for I see a decline in the use of Boost. This is despite the fact that our build system makes Boost available *by default*, it's an implicit dependency nobody has to care about! There are projects that no longer use Boost because of the noticable increase in compile times. There are projects that replace Boost libraries with non-Boost libraries that have no or much shorter dependency chains. There are projects that spend serious efforts to create alternatives to existing Boost libraries. Because of all of that, I'll drop as much from the next distribution as I possibly can and divert my time elsewhere. I don't like that, but this is how things are in 2024. Thanks, Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5