Richard Hodges wrote:
On Thu, 25 Sept 2025 at 17:15, Peter Dimov via Boost <boost@lists.boost.org> wrote:
You need strlen for more than size(). It's also needed in end(), operator[], at(), remove_prefix, substr (both overloads), the find functions taking a start offset, back(), actually everything taking a start offset, ends_with, and probably others as well.
If the purpose of the class is to provide the functionality of a c string, then the only required methods are those available on a c string: - data - array indexing - length
There is no need for any string manipulation. In C++,.the correct class for string manipulation operations is a std::string
There is a reasonable argument that you may want begin() and end() iterators, maybe. But it's reasonable to write end() in terms of strlen(), because it's unlikely that a sane program will need to call end() more than once, and also unlikely that it will need to call both end() and size(), when dealing with a c string.
Computing the length of a string with strlen() is very high performance for anything other than an extremely long string.
I don't think this thing needs to be over-engineered. I am of the view that providing a full std::string interface is an utter waste of time and effort.
All the cstring_view/zstring_view implementations, and all the standardization proposals thereof, are converging on it being exactly like string_view, with a null terminator invariant. That's kind of the point of the class; to allow you to use the string_view interface instead of <cstring> functions (as is the case when char const* is used.) The idea that we're somehow delivering enormous value by making it clear that the parameter is not a pointer to a single `char` is misguided; pointers to a single `char` are so rare that a `char const*` is essentially an idiomatic way to denote a null terminated char sequence. Its downside is not lack of type safety.