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 …
[View More]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)
[View Less]
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 …
[View More]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.
[View Less]
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 …
[View More]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.
[View Less]
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 …
[View More]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
[View Less]
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
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 …
[View More]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
[View Less]
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
> >> …
[View More]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
[View Less]
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
> …
[View More]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
[View Less]
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 …
[View More]<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
[View Less]
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 …
[View More]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
[View Less]
