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#we...
It doesn't really matter how many dependencies Boost.Thread adds. What
matters is how expensive
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.