On Wed, Jul 16, 2025 at 1:15 PM Jonathan Wakely <jwak...@redhat.com> wrote:
> On Wed, 16 Jul 2025 at 11:47, Tomasz Kaminski <tkami...@redhat.com> wrote:
> >
> >
> >
> > On Wed, Jul 16, 2025 at 12:07 PM Jonathan Wakely <jwak...@redhat.com>
> wrote:
> >>
> >> This change was part of by P2697R1 (Interfacing bitset with string_view)
> >> and should be slightly cheaper to instantiate.
> >>
> >> libstdc++-v3/ChangeLog:
> >>
> >> * include/std/bitset (__bitset::__string) [__cpp_lib_bitset]:
> >> Change alias to refer to basic_string_view instead.
> >> ---
> >>
> >> Tested x86_64-linux.
> >>
> >> libstdc++-v3/include/std/bitset | 5 ++++-
> >> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libstdc++-v3/include/std/bitset
> b/libstdc++-v3/include/std/bitset
> >> index 61756350cc9c..92f11f19807a 100644
> >> --- a/libstdc++-v3/include/std/bitset
> >> +++ b/libstdc++-v3/include/std/bitset
> >> @@ -720,7 +720,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> >>
> >> namespace __bitset
> >> {
> >> -#if _GLIBCXX_HOSTED
> >> +#ifdef __cpp_lib_bitset // ...construct from string_view
> >
> > Could we change this condition to __glibcxx_string_view, i.e. use
> string_view
> > when it does exist?
>
> I think we could do, I went with the minimal conservative change for now.
>
> > Or are we concerned about the possible change of signature of the
> constructor,
> > and using a different specialization of _M_copy_from_ptr in C++17 mode?
>
> I'm not concerned about that, no. The signature will mangle
> differently, but users can't take a constructor's address so can't
> tell that if it changes.
>
> I don't think we can get a different specialization of
> _M_copy_from_ptr unless _CharT is a program-defined type (e.g. an
> unscoped enum), and std::basic_string<C>::traits_type is not
> std::char_traits<C>, but I don't think that's allowed?
> So in the constructor body, I think we could replace:
> using _Traits = typename __bitset::__string<_CharT>::traits_type;
> with just std::char_traits<_CharT>. That's defined for freestanding
> (at least the parts we need: length and eq).
>
> I don't think a program-defined specialization of basic_string<C,T> or
> basic_string_view<C,T> is allowed to define traits_type to anything
> except T, and so for basic_string<C> T has to be std::char_traits<C>,
> and so the specialization of _M_copy_from_ptr is always fixed.
>
> I did check that size_type and npos aren't affected, but because we're
> always using basic_string<C> (i.e. no program-defined allocator) it
> means that size_type is the same as basic_string_view<C>::size_type,
> i.e. size_t.
>
> But if it's safe to assume that basic_string_view<C>::size_type is
> size_t, then why doesn't the constructor signature just say that? Why
> do we need to instantiate a string or string view at all? Maybe that
> would be a better resolution for LWG 4294.
>
> Anyway, for now I think I'd prefer to only change to
> basic_string_view<CharT> for C++26, and if nobody complains that it
> stopped using their program-defined specialization of
> basic_string<CharT> we can consider changing it for C++17/20/23 as
> well.
>
That makes sense to me. Thanks for the detailed explanation.
The original change LGTM.
