[boost] The future and present of 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.

+1

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 
others.*

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 
  them. 

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
arguments.

> 
> > 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 
standardization.

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

Mike
 
> Robert Ramey