Re: [boost] The new Boost 17.0.0

On Tue, Dec 1, 2020 at 4:16 PM Antony Polukhin wrote:

On Tue, Dec 1, 2020, 23:36 Glen Fernandes wrote:

...

On Tue, Dec 1, 2020 at 3:27 PM Antony Polukhin wrote:

...

Exactly that's the problem I'm trying to solve with the Boost17. The problem becomes much bigger, when the Boost library becomes part of the iterface. For example, Boost.DLL needs shared_ptr and filesystem in it's interface. Users suffer from boost::filesystem and boost::shared_ptr if their projects use C++17 std:: alternatives.

Why haven't you solved it for Boost.DLL users by switching to std::shared_ptr and std::filesystem yet? You don't need anyone's permission.

Because I'm not planning to drop support for the pre-C++17 users. I wish to provide another library for users that avoid existing Boost.DLL because of the dependencies.

Wich brings me to a less radical idea: we may simplify acceptance of dependenceless library clones. Next step would be to provide predefined bcp'ed subsets of libraries (boost 17, boost 23?)

One option is for that other library (DLL for C++17+) to still live under the boostorg/dll repository - i.e. it doesn't need to have its own repository. If so, there's no concern about acceptance either since you already have it (you can maintain both under boostorg/dll and then eventually choose to drop the C++03 variation in a later Boost release etc...). Glen