Re: [boost] Revitalization

On Dec 5, 2022, at 6:58 PM, Vinnie Falco wrote:

On Mon, Dec 5, 2022 at 6:36 PM Proton wrote:

...

I am willing to assist other maintainers in offering a standalone module of their libraries.

Sloooooooooow down there cowboy :)

I'm not suggesting to start turning out a series of Boost libraries converted to standalone. That's not going to be practical, because there are Boost facilities that are too darn good to do without:

Boost.Align - everything Boost.Assert - BOOST_ASSERT, source_location, current_function Boost.Config - everything Boost.Container - memory_resource for C++11 Boost.Core - string_view, allocator_traits Boost.Describe - practical reflection Boost.Mp11 - everything Boost.System - error_code, result Boost.ThrowException - throw_exception (attached stacks) Boost.Variant2 - A never valueless variant (how it should have been)

These libraries are important for me and I find myself using them in every single project I author. The features fall into several categories:

* Utilities to help code work on all toolchains * C++11 implementations of C++17 or later features (string_view, variant2) * Better versions of things in C++ (throw_exception, error_code) * Features that would be a pessimization to have to reimplement (Mp11, Describe, et. al.)

The original release of Boost.JSON had a "standalone" mode but I quickly ran into the problem where denying myself access to all of the useful libraries described above became unworkable.

We might consider offering smaller a-la carte bundles of Boost libraries. For example, bundle the libraries above into a "Boost Essentials." Of course this might be a dumb idea and I will not be offended if anyone says so. Making Boost.JSON, Boost.URL, Boost.HTTP.Proto "mostly standalone" (i.e. depend only on a "Boost Essentials" type library) is much more realistic than having to make it totally standalone and reimplement everything over and over.

There is also another problem which is that as I write higher level libraries, I depend on the lower level libraries. For example:

Beast depends on Asio HTTP.Proto depends on URL HTTP.IO depends on HTTP.Proto and Asio

A hypothetical "Boost.HTTP.Requests" library would depend on Asio, HTTP.Proto, HTTP.IO, and Boost.JSON.

And so on. It is not sustainable to try to make every single library standalone. This subverts the benefits of separation of concerns and physical separation of libraries. Instead we should focus on how we can make it more palatable for users to add our libraries to their project, if not the singular monolithic Boost installation, then perhaps the smaller library aggregates I alluded to above.

Thanks

For higher level libraries bundling is certainly more practical. I think there are other libraries like Math that don’t require anything Boost for proper functionality. Most of Math’s Boost dependencies were features replaced in C++11 (e.g. array, atomic, type_traits, etc.). Either way, we are experiencing success moving away from the monolithic dependency, and I expect others would have a similar reception. Matt