- Boost - lists.boost.org

Re: [boost] Boost.Compat
by Dominique Devienne 28 Apr '23

28 Apr '23

On Thu, Apr 27, 2023 at 5:16 PM Peter Dimov via Boost <boost(a)lists.boost.org> 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)

1 0

Re: [boost] BOOST_NO_STD_LOCALE & BOOST_NO_STD_WSTREAMBUF
by John Maddock 28 Apr '23

28 Apr '23

On 27/04/2023 23:19, Robert Ramey via Boost wrote: > in boost/config/detail/suffix.hpp > > I find this bit of code: > > // > // We can't have a working std::wstreambuf if there is no std::locale: > // > # if defined(BOOST_NO_STD_LOCALE) && !defined(BOOST_NO_STD_WSTREAMBUF) > # define BOOST_NO_STD_WSTREAMBUF > # endif > > and believe it or not. this is now causing me some issues. Is the > statement above true? Do we know that wide char streams cannot exist > without std::locale being present? Can anyone shed light on this? As already mentioned, the original logic (and this dates back to C++98 or maybe even earlier!) was that there was a direct dependency between the "new" iostream operators and std::locale. I'm sure that for 99% of platforms this is redundant now anyway given that everyone supports wchar_t. What's the specific issue this is causing? John.

1 0

Re: [boost] BOOST_NO_STD_LOCALE & BOOST_NO_STD_WSTREAMBUF
by Gavin Lambert 28 Apr '23

28 Apr '23

On 28/04/2023 13:07, Glen Fernandes wrote: >> in boost/config/detail/suffix.hpp >> I find this bit of code: >> // >> // We can't have a working std::wstreambuf if there is no std::locale: >> // >> # if defined(BOOST_NO_STD_LOCALE) && !defined(BOOST_NO_STD_WSTREAMBUF) >> # define BOOST_NO_STD_WSTREAMBUF >> # endif >> >> and believe it or not. this is now causing me some issues. Is the >> statement above true? Do we know that wide char streams cannot exist >> without std::locale being present? Can anyone shed light on this? > > Not just std::wstreambuf but also std::streambuf. ie. std::basic_streambuf > depends on std::locale. But does it really? I could imagine that in some embedded platform std::locale could be omitted (since it's huge, rarely used, insufficient for purpose, and everyone hates it anyway), and in that implementation it could be presumed that no such dependency exists either, so long as you don't try to actually call the omitted methods.

1 0

Re: [boost] BOOST_NO_STD_LOCALE & BOOST_NO_STD_WSTREAMBUF
by Glen Fernandes 28 Apr '23

28 Apr '23

On Thu, Apr 27, 2023 at 6:13 PM Robert Ramey via Boost < boost(a)lists.boost.org> wrote: > in boost/config/detail/suffix.hpp > I find this bit of code: > // > // We can't have a working std::wstreambuf if there is no std::locale: > // > # if defined(BOOST_NO_STD_LOCALE) && !defined(BOOST_NO_STD_WSTREAMBUF) > # define BOOST_NO_STD_WSTREAMBUF > # endif > > and believe it or not. this is now causing me some issues. Is the > statement above true? Do we know that wide char streams cannot exist > without std::locale being present? Can anyone shed light on this? > Not just std::wstreambuf but also std::streambuf. ie. std::basic_streambuf depends on std::locale. Glen

1 0

BOOST_NO_STD_LOCALE & BOOST_NO_STD_WSTREAMBUF
by Robert Ramey 27 Apr '23

27 Apr '23

in boost/config/detail/suffix.hpp I find this bit of code: // // We can't have a working std::wstreambuf if there is no std::locale: // # if defined(BOOST_NO_STD_LOCALE) && !defined(BOOST_NO_STD_WSTREAMBUF) # define BOOST_NO_STD_WSTREAMBUF # endif and believe it or not. this is now causing me some issues. Is the statement above true? Do we know that wide char streams cannot exist without std::locale being present? Can anyone shed light on this? Robert Ramey

1 0

Re: [boost] Boost.Compat
by Christian Mazakas 27 Apr '23

27 Apr '23

I'm the author of the <latch> PR for Core so I'm also naturally in favor of this addition. What's the protocol for accepting such a library into Boost? Does it still go through formal review? Most of what would go in there exists in already-accepted Boost libraries. For example, the aforementioned Boost.Algorithm and Boost.Core contains several such things as <span>, <bit> and in its detail folder, <string_view>. The good news though is that because we're simply polyfilling standardized practice, there's no need to bikeshed interfaces. Oh, I almost forgot about Boost.Optional. How do we reify all of these existing classes and functions? - Christian

1 0

Re: [boost] Boost.Compat
by Zach Laine 27 Apr '23

27 Apr '23

On Thu, Apr 27, 2023 at 11:21 AM Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > On Apr 27, 2023, at 8:31 AM, Glen Fernandes via Boost <boost(a)lists.boost.org> wrote: > > > > On Thu, Apr 27, 2023 at 11:24 AM Peter Dimov via Boost < > > boost(a)lists.boost.org> wrote: > > > >> 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.) > >> > > > > > > For the rest of the list: I'm in favor of this (as my response in the > > Core thread indicates). > > There’s a lot of this kind of stuff in Boost.Algorithm > > Boost/algorithm/cxx11, for example. Ha. Read first, then post, Zach. Zach

1 0

Re: [boost] Boost.Compat
by Zach Laine 27 Apr '23

27 Apr '23

On Thu, Apr 27, 2023 at 10:16 AM Peter Dimov via Boost <boost(a)lists.boost.org> 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.) I like this idea a lot. I want to mention that there are lots of places currently that do a partial job of this. One conspicuous one is Algorithm. There are probably lots of others. Having one place to get all the compatibility bits would be very welcome. Zach

1 0

Re: [boost] Boost.Compat
by Marshall Clow 27 Apr '23

27 Apr '23

On Apr 27, 2023, at 8:31 AM, Glen Fernandes via Boost <boost(a)lists.boost.org> wrote: > > On Thu, Apr 27, 2023 at 11:24 AM Peter Dimov via Boost < > boost(a)lists.boost.org> wrote: > >> 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.) >> > > > For the rest of the list: I'm in favor of this (as my response in the > Core thread indicates). There’s a lot of this kind of stuff in Boost.Algorithm Boost/algorithm/cxx11, for example. — Marshall

1 0

Re: [boost] Boost.Compat
by Glen Fernandes 27 Apr '23

27 Apr '23

On Thu, Apr 27, 2023 at 11:24 AM Peter Dimov via Boost < boost(a)lists.boost.org> wrote: > 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.) > For the rest of the list: I'm in favor of this (as my response in the Core thread indicates). Glen

1 0