From: Peter Dimov (pdimov_at_[hidden])
Date: 2024-02-08 16:01:00
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.
(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.