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]>
> 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
> > >> 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
> > > resources to maintain two forks. In reality, we have trouble
> > > 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
> > were.
> Nice for the end user, perhaps, but intermediate libraries are now forced
> choose between using boost or boost2, or maintaining two versions.
> My alternative idea of "nice to have" is a single Boost library that can
> either boost or std components in its interface. That's not always
> 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
Splitting Boost.DLL into std17 and current-Boost libraries fixes 3 issues
out of 4.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk