Re: Boost.Compat

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-04-30 12:50:51

On 4/30/23 15:18, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>> On 4/30/23 02:18, Peter Dimov via Boost wrote:
>>> Andrey Semashev wrote:
>>>> And lastly. I realize that the proposed Boost.Compat is supposed to
>>>> contain direct equivalents of the standard components. But what if we
>>>> want to improve on that? Would this be not allowed simply because
>>>> this would deviate from the standard?
>>>
>>> No, it wouldn't be allowed. Improving upon the standard makes it
>>> impossible to later replace the compatibility header with a using
>>> declaration. We have such a problem today with e.g. Boost.Ratio and
>>> Boost.Chrono, where because of extensions we can't simply make them be
>> <ratio> and <chrono>.
>>>
>>> It's fine to want to improve upon the standard, but Compat will not be
>>> the place for that. That's what dedicated libraries are for.
>>
>> This would mean more code duplication, wouldn't it?
> 
> It's a tradeoff as any other. You need <latch>. Since it's trivial to implement
> over C++11, you add a private implementation to your library. This duplicates
> the one in Boost.Thread. But you don't want to depend on Boost.Thread,
> because if you don't need C++03 support or thread interruption, it duplicates
> the standard library, and adds 50 dependencies.
> 
> https://pdimov.github.io/boostdep-report/boost-1.82.0/module-weights.html#weight:50

It doesn't really matter how many dependencies Boost.Thread adds. What
matters is how expensive <boost/thread/latch.hpp> is. Personally, I
would have no problem depending on it, if I really needed this component.

> In addition, the code duplication in Compat will gradually disappear as its
> minimum C++ standard level is raised. E.g. shared_mutex.hpp (assuming
> we have it) will effectively disappear at 14. latch.hpp will disappear at 20.

This will happen when? I don't imagine Boost is raising its minimum C++
version to C++14, let alone 20 any time soon.

> We can't clean up Boost.Thread in this manner even if we impose a C++11
> requirement, since it has to provide its own primitives for everything
> because of thread interruption.
> 
> But you know this because that's what the Sync intro says. :-)

Regarding thread interruption, we could simply deprecate it and remove
over time. I think, that was one of the ideas behind Boost.Sync - e.g.
boost::mutex from Boost.Thread would get deprecated in favor of
boost::sync::mutex from Boost.Sync.

It might not be too late to revive Boost.Sync and add a latch
implementation there.