Boost logo

Boost :

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2024-03-27 17:20:01


On Wed, Mar 27, 2024 at 10:07 AM Daniela Engert <dani_at_[hidden]> wrote:

> That's a diverse collection of criteria that may or may not guide adoption
> of new libraries into Boost.
>

To clarify, I was suggesting that some of the criteria be met, not
necessarily all.

> 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).
>
Ah, yes, thank you so much for this. It neatly expresses my thinking on the
matter.

Some may say the review process determines what belongs in Boost. But there
is no documented vision nor mailing list discussion one can point to for
guidance. Every reviewer has their own opinions, and the result is enormous
variance in quality or focus.

> - 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.
>
It seems to me that this is the most accurate description of the current
state of affairs.

> When I look at the projects in the company that I work, for I see a
> decline in the use of Boost.
>
As you noted, there is a cost that comes with using Boost in a project. I
understood this right away as I tended to avoid Boost in the past unless
absolutely necessary. When I design my libraries, this cost is always front
of mind. By making my library a Boost library, I am expecting users to
accept that Boost has its own error_code and other types that duplicate std
functionality. Users also accept the varying quality and big footprint in
terms of the number of additional files. I try to create a library that is
so good, whose functionality cannot be found elsewhere at similar quality,
that users will accept the costs of integrating Boosts in exchange for
having access to my libraries.

If the bar for technical excellence is not high with respect to which
libraries are considered good candidates for Boost, then users will not
find the value proposition compelling. In other words no one is going to
put up with the costs of integrating Boost just to have access to a bunch
of mid-tier libraries they could easily get elsewhere without Boost.

Thanks


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk