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/forma...
https://github.com/boostorg/log/blob/develop/include/boost/log/utility/forma...
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.