Boost logo

Boost :

From: James E. King III (jking_at_[hidden])
Date: 2022-05-05 15:51:35


On Thu, May 5, 2022 at 10:59 AM Mateusz Loskot via Boost
<boost_at_[hidden]> wrote:
>
> On Thu, 5 May 2022 at 16:26, Kostas Savvidis via Boost
> <boost_at_[hidden]> wrote:
> > [...]
> > In other words, boost needs to shrink not grow.
>
> I mostly agree, but I'd say Boost needs to undergo a restructurisation to
> remain attractive to all generations of developers, maintainers and users.
>
> I can't see it happen unless we have separate superprojects:
>
> github.com/boostorg/boost (require>=C++17)
> github.com/boostorg/boost11 (>=C++11 )
>
> and, if still relevant, perhaps:
>
> github.com/boostorg/boost03
>
> As a maintainer, I'd like to be free to maintain a library
> only for e.g. boostorg/boost and forget about
> boostorg/boost11, or let new maintainer to take it
> over there.

About shrinking boost:

I see no reason to have separate superprojects for different language
levels. Why not simply have a concerted effort to remove C++03
support? If people still are using C++03 then they can use an older release
of Boost until they make the transition. Stop testing it, stop saying it works,
and allow C++11 in those libraries. The savings to CI time alone would be
quite profound.

I would like to see the floor move to C++11 at this point. In cases where
the standard library has implemented something like what boost delivers
in the C++11 standard, then it would also be reasonable to drop those boost
libraries because, again, people can use an older release of Boost until
they make the transition.

If the project regularly claimed support for 3 back-revisions of language
then with C++23 is released, C++20, C++17, C++14 would be "officially"
supported and C++11 would be dropped. That simply means it is no longer
tested or fixes made; people can use an older boost version until they make
the transition. Having a hard-and-fast rule like this makes things way more
predictable for all of us and all the consumers.

About C++ in general (20/50 yrs):

In comparison to other languages, C++ package management still seems
like it is struggling. I guess you can use conan and cmake together but
I haven't done enough to know how easy or difficult it is to do, and it looks
like there are platform specific instructions for either. Having worked with
python, javascript, perl and rust as well, the package management systems
have their warts but generally make it a lot easier to consume external work
and release work to others. It is a significant weakness in the ecosystem.

- Jim


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