[boost] The future and present of Boost

Sorry, somehow this excellent response to my post got lost in my inbox.

-----Original Message----- From: Boost 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 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