Boost logo

Boost :

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
for free.

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, gregod at, cpdaniel at, john at