Re: Should boost::core::string_view be made public?

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-02-08 16:22:08

On 2/8/24 19:01, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>> On 2/8/24 18:10, Peter Dimov via Boost wrote:
>>> Andrey Semashev wrote:
>>>> I'll add that this will not be a free transition for other libraries
>>>> that support or use string views. For example, in Boost.Log I support
>>>> boost::string_view and boost::string_ref but not
>>>> boost::core::string_view. Not that it should be difficult to switch,
>>>> but it's work. It's more complicated if the library or tool is unmaintained.
>>>
>>> core::string_view is intended to be the single type you need to
>>> support. It converts from (and to) boost::string_view in addition to
>> std::string_view.
>>
>> No, conversion won't work as I need to detect string types and process them
>> specially (perform character code conversion). And for arbitrary types I need
>> to forward to the type's own operator<<.
>>
>> https://github.com/boostorg/log/blob/develop/include/boost/log/utility/formatting_ostream.hpp#L558-L710
>>
>> https://github.com/boostorg/log/blob/develop/include/boost/log/utility/formatting_ostream.hpp#L900-L959
> 
> Yes, I see. I agree that core::string_view isn't going to simplify this code.
> 
> I note that you're throwing away OtherTraitsT at earliest opportunity, which
> almost certainly means you're copying values of OtherCharT without going
> through OtherTraitsT::copy and OtherTraitsT::assign. Is that legal? Nobody
> knows or cares because nobody uses traits other than std::char_traits.

I'm not copying or assigning characters within the argument string, so I
don't think I'm supposed to use OtherTraitsT.

> (Well, maybe stdlib implementers do know and do use them in test suites.)
> 
> The sooner traits type die, the better. Unfortunately that would be never.