Re: The new Boost 17.0.0

From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2020-12-01 20:05:40

On Sun, Nov 29, 2020, 01:02 Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> Rainer Deyke wrote:
> > On 28.11.20 19:07, Peter Dimov via Boost wrote:
> > > Rainer Deyke wrote:
> > >
> > >> From a user perspective, forking is an improvement over the status
> quo:
> > >> it means that Boost can guarantee that the 1.x line can stop dropping
> > >> support for old C++ standards, making it relatively safe to upgrade
> > >> within the 1.x line.
> > >
> > > This is only an improvement in the imaginary world where we have
> enough
> > > resources to maintain two forks. In reality, we have trouble
> maintaining
> > > one.
> >
> > Yes, that's why I wrote "from a user perspective".  I'm not saying that
> > this a practicable solution.  I'm just saying that it would be nice if
> it
> > were.
>
> Nice for the end user, perhaps, but intermediate libraries are now forced
> to
> choose between using boost or boost2, or maintaining two versions.
>
> My alternative idea of "nice to have" is a single Boost library that can
> use
> either boost or std components in its interface. That's not always
> possible
> to obtain though.
>

I've tried that and it kind of works. There are still problems:
* users have to use macro to customize the library
* bcp still pulls in the Boost alternatives
* code redability suffers from typedefs
* you still kind of have two different libraries

Here's how it works on Boost.DLL:
* users define BOOST_DLL_USE_STD_FS
* bcp still puls in Boost.Filesystem, Boost.System...
* boost::dll::fs::path = std::conditional_t<a-lot-of-mess>
* code in incompatible with the library that was build without
BOOST_DLL_USE_STD_FS

Splitting Boost.DLL into std17 and current-Boost libraries fixes 3 issues
out of 4.

>