Re: [boost] The future and present of Boost

Subject: Re: [boost] The future and present of Boost
From: Peter Koch Larsen (peter.koch.larsen_at_[hidden])
Date: 2018-10-23 08:40:36

I agree with Niall.
I have been using boost for many years and would love that feature to
be part of the documentation.
A library that is not maintained puts a bad reputation on boost. And
while I used to think that being part of boost would be synonymous
with high quality and good performance, this is not always the case
anymore.
Boost still contains a number of very good quality libraries, but the
age is beginning to show.

On Tue, Oct 23, 2018 at 10:29 AM Niall Douglas via Boost
<boost_at_[hidden]> wrote:
>
>
> >> [1] I really, really, really, really wish Boost would expunge the
> >> undermaintained libraries already. They waste productivity for so many
> >> people out there who think they're using a Boost quality library, when
> >> they're not, and get badly burned for it.
> >>
> > Could you be more specific?  Which libraries need attention?
>
> Oh I've been quite specific in the past. I've given up trying.
>
> > If you want
> > to reply directly I can work with the CMT to assess.  Issues like this need
> > to be brought up on the mailing list if folks thing something is being
> > neglected.
>
> A long time ago I made a list of Boost libraries ordered by the number
> of open, unresolved issues weighted by their age squared. The library
> which comes top of that list nobody would say isn't maintained, but the
> next few are very likely candidates for expunge. They don't have a
> maintainer, have long standing severe bugs which ruin productivity for
> their users, and worst of all, *do not advertise their low quality* in
> their documentation. They are also not core libraries, so removing them
> won't break other Boost libraries.
>
> Me personally, for each library without a maintainer I'd print a box at
> the top of every page in their documentation showing how many open bugs
> there are, and the average age of that open bug. Plus a wee note asking
> for somebody to step up to take over as maintainer. That means Boost
> stops lying to its user base wrt to its patchy quality.
>
> > We do have some procedures for dealing with this.  I know we need to find
> > new
> > homes for libraries that Beman was maintaining.
>
> Somebody, not me, ought to make a Boost.Filesystem v4 written using
> LLFIO. It would be an enormous improvement on STL <filesystem>, and
> would be the basis for the future reform of STL <filesystem>, which has
> a lot of problems.
>
> > We're removing Boost.Signals(v1) in 1.69.0.  It was deprecated for.. a long
> > time.
> > (too long...)
>
> My personal biggest bugbear is Boost.Iostreams. It should have been
> deprecated years ago. And I keep answering questions by perplexed users
> on StackOverflow who have sunk significant costs into adopting that
> library, and then find out to their horrible surprise that their work
> must be completely discarded and they have to start again with a
> non-fundamentally-broken alternative.
>
> Thankfully, we are on course to be able to offer in the C++ standard
> library a somewhat complete alternative to Boost.Iostreams by C++ 23,
> god willing.
>
> Niall
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost