Re: [boost] List of C++ 11 only Boost libraries and their status?

Subject: Re: [boost] List of C++ 11 only Boost libraries and their status?
From: Thijs van den Berg (thijs_at_[hidden])
Date: 2014-11-28 05:21:37

On Thu, Nov 27, 2014 at 11:12 PM, Robert Ramey <ramey_at_[hidden]> wrote:

> Gottlob Frege wrote
>
>
> > The further question, which I think should be discussed here or at
> > BoostCon/C++Now, is what is Boost's role *today*?  Is boost still a
> > stepping stone to the standard? (I find that with the standard's new
> > pace, and with its push to use TS's, "stepping stone" is now a more
> > minor role for boost.  For better or worse - ie I'm not sure if it is
> > good for the standard.)
> > Or is boost now a place for good libraries, most of which aren't
> > general enough to be in std, but are really good and really useful
> > when you need them?
> > Or is boost a maintenance effort for old libraries for older
> > compilers.  (I don't think Boost is just that, but is it part of its
> > role?)
>
> Of course this is the key question.  My views on these questions
> are pretty simple
>
> a) The C++ world needs many more good libraries
> b) Adding many more libraries to the standard is not sustainable
> c) Therefore, the role of boost should shift away to making libraries
> for the standard toward making good C++ libraries in general.
>
I agree with c). IMO to facilitate that we need to move away from the
monolithic codebase identity of boost and shift towards a repository of
"boot-style reviewed and documented libraries" that are separately
downloadable.

If we allow for many libraries (e.g. 500) then we should allow for all 3
libraries  "sort" and a "algorithms" and a "radixsort" (to pick a recent
discussion) to live side-by-side because overlap like that are bound to
happen with 500 libraries. I see that happen in other languages that have
many libraries like python, R, and it's no problem. Allowing for overlap
also makes it more clear that boost  is no longer monolithic codebase. It
also makes things easier for library developers.

Regarding the support for old compilers: in front-end web development you
have "normalization" libraries (eg http://necolas.github.io/normalize.css/)
that try to make webpages work and look the same on all types of browser.
In earlier discussion normalization has been part of an idea called a
"core" library but it could be a standalone library that focuses on
compatibility and compiler support.