Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2023-04-30 12:17:54


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

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.
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. :-)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk