On Sun, Nov 29, 2020, 01:02 Peter Dimov via Boost
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
Rainer Deyke wrote: 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.