Re: The new Boost 17.0.0

From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2020-12-01 21:23:10

On Tue, Dec 1, 2020 at 4:16 PM Antony Polukhin <antoshkka_at_[hidden]> wrote:
>
> On Tue, Dec 1, 2020, 23:36 Glen Fernandes <glen.fernandes_at_[hidden]> 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