Subject: [boost] The future and present of Boost
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-10-24 13:45:52
Sorry, somehow this excellent response to my post got lost in my inbox.
> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Robert Ramey via Boost
> Sent: Monday, October 22, 2018 4:26 PM
> On 10/22/18 1:53 AM, Mike Dev via Boost wrote:
> >> -----Original Message-----
> >> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Robert Ramey via Boost
> >> Sent: Monday, October 22, 2018 3:33 AM
> >> But now Ranges may come as part of the standard in C++20. And then
> >> sometime after may be available when/if compiler vendors choose to
> >> implement their own version. All in all, the committed would have been
> >> able to spend time on other stuff which only they can do.
> > They would still have had to spend the time on standardizing ranges-v3.
> My point is that complex libraries such as ranges, networking, etc.
> don't belong in the standard at all. So in my world, the committee
> would spend zero time on these things - thus making available time on
> those things that only a standards committee can do.
I completely agree for e.g. networking, graphics and similar proposals.
However, I really want to have ranges in the standard, because they
establish a framework of patterns and concepts around which other libraries
can form. If I want to compose multiple algorithms from different libraries
easily, they need to have a common format (an in case of ranges some
scaffolding) and establishing this format is very difficult for an external
library, even if it is widely used.
> > I don't see how ranges-v3 being in boost instead of a stand-alone repo
> > would have made any difference for standardization, unless you assume
> > that it would have produced a much superior design.
> Hmmm - the question posed really is whether Boost adds any value at all.
> That is, if a boost library is equivalent to any other library on
> github, then what's the point of Boost. This is actually the
> fundamental question that Boost has to face today.
Form me (as a user) there are some main properties that I automatically
attribute to a boost library even if I haven't heard of it before:
- I expect the quality of implementation to be generally quite good
thanks to being reviewed at least once and usually having quite a few
users that would surface most bugs.
- I expect at least some level of support for the library for some
years to come (it will not just be dropped as soon as the author
starts working on a different, more interesting project).
I'd certainly not make such assumptions about the latest "random github
library" hyped on reddit without extensive (and time consuming) research.
*That's the value the "boost label" provides for me and I guess many
And yes, boost has to be careful not to lose this status by dragging
along libraries that are no longer properly maintained. I've seen James
King in particular doing a lot of work to prevent that and I'm sure other
members of boost are active in that direction too, but there is just so
much work the CMT and other library maintainers can be expected to do
In any case, even ignoring maintenance backlog on individual libraries,
this "boost label" also comes with some annoyances that - for me and
some others on my team - start to outweigh the aforementioned benefits:
- The build process. Every time I need to build boost with a non-
standard configuration (let's say I want to enable sanitizers,
build against libc++ instead of libstdc++ or cross compile to and
embedded target) I'm spending hours until if find out how to make
sure the (non-header-only) boost libraries get build with the proper
flags using the correct toolchain and how to hook up that version of
boost with the right version of my application.
Almost every other modern OS library on github provides a cmake
file that allows me to just add the repository into a subfolder of
my project and call add_subdirectory(libs/library) and it will just
adopt whatever build configuration is handed down from my Project's
cmake file (Or rather the appropriate toolchain file).
Don't get me wrong: b2 is certainly a wonderful build system and
for "normal" builds where I can use vcpkg or the like I don't care
how boost is build.
- Unnecessary dependencies. All the projects I'm working on nowadays
are c++14 or even 17. Why the hell does the latest version of my
preferred boost library X still have a dependency on boost library Y
that has been merged into the standard since c++11 or been superseded
by c++11 language feature? It just adds complexity to the build
process, increases compile times and sometimes leads to subtle bugs.
I'm paying (sometimes little sometimes heavily) for something I don't
use/need (c++98 compatibility).
- Implementation complexity. This goes hand in hand with the previous
point: Some boost libraries are full of #ifdefs to work around
problems in compilers that are more than a decade old
(NOTE I'm not talking about necessary workarounds for "recent" compilers
like e.g. gcc 4.8 or even VS 2015) while simultaneously wanting to
support the latest c++17 vocabulary types in their interface. Others also
use ridiculously complex TMP constructs that are only necessary because
they can't use post c++03 language features.
I understand why those things have been necessary when the libraries
where original created, and I understand that there are still users
that can't use a c++11 library or a more modern compiler, but I don't
know why the latest version of a boost library still has to cater to
In my dream world, individual boost libraries would much more often make
a major version bump that adopts new language facilities and drop support
for older compilers instead of having a single code base that tries to
simultaneous support all language standards from c++98 to c++20 across
5 different toolchain families and on 10 different platforms
(I'm exaggerating of course but that's how it sometimes feels).
Note that such a version bump doesn't necessarily imply a new API
This would go hand in hand with deprecating and removing libraries that
got merged into newer versions of the c++ standard.
As always people like me tend to complain more about the things that
annoy them than praise the things that help them so don't take the
length of the pro/con sections as an indication of the weight of the
> > Also, considering that the "actual" ranges library depends on
> > concepts,
> I'm not sure that it necessarily depends on concepts. But even if it
> does, Eric implemented his own library based version of concepts. Paul
> Fulks was inspired by that to propose such a library for boost which
> failed to pass review.
> >I don't see how that work could have been done as part of a
> > boost library which is commonly expected to work with a wide variety of
> > compilers / compiler versions.
> I believe that Eric's and Pauls were both portable.
I was talking about the library that was the reference implementation for
the ranges-TS and which required an implementation of the concpets-TS only
provided by gcc (I forgot the name). That was the one relevant for
Ranges-v3 (the c++11 version with the library implementation of concepts)
is certainly a nice library that can be used by more people but e.g.
compile-times were a real bummer and it still doesn't compile on msvc.
Also quite frankly: Given that it is yet another library that emulates
a native language concept with insanely complex TMP machinery, I'd hate
to see that library as a dependency of other header-only boost libraries
whose compile-times will then remain insanely high years after real
concepts have entered the standard. And I'm not sure if anyone will
want to spend the time to properly maintain it once Eric moves on.
Sorry for the long post
> Robert Ramey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk