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.
