Boost logo

Boost :

From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2023-04-28 11:49:37


On Thu, Apr 27, 2023 at 5:16 PM Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> Newer C++ standards (20) have been adding useful things to the
> standard library (<bit>, <latch>, etc) and most of us would like to
> use them, both in Boost and outside of it, while still supporting
> C++11, or 14, or 17.
>
> Many of these components are straightforward to implement
> using the C++11 standard library, consist of not much than one
> relatively small header, don't need many Boost dependencies
> beyond the required ones (Assert, ThrowException, Config), and
> since their interface is already fixed by the standard, don't need
> a design review.
>
> It would be nice if we had a dedicated place in Boost where to
> put these, to avoid the need for everyone reimplementing a
> private copy.
>
> At the moment, some of these have gone into Core, for lack of
> anywhere else, and we now have a <latch> contribution (which I
> encouraged):
>
> https://github.com/boostorg/core/pull/144
>
> However, Core is not quite the right place for these components.
>
> So my suggestion is to create a separate library/repo, Boost.Compat
> (boostorg/compat, namespace boost::compat) for them.
>
> Thoughts? (Be sure to read the discussion in the PR as well.)
>

+1.

I'm on C++17, and have adopted std::span and others from C++20/23,
from various places on GitHub. I'd welcome Boost-provided "polyfills" [1]
instead. Of course, Boost.Compat (or Boost.Polyfill) would need to turn
on/off
its std:: alternatives depending on the standard level in use. --DD

PS: Since we update our Boost dependency rarely, I sometimes drop newer
  Boost libs (e.g. Boost.Describe) in our code-base, and hope for
backward-compatibility
  with our old Boost install. So if Boost.Compat could be similarly
backward-compatible,
  that would increase the likelyhood we could use it sooner rather than
later.

[1] https://en.wikipedia.org/wiki/Polyfill_(programming)


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