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/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.
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.