Why not delay the detection of the length to the first call of strlen?   What it should do: -> Confirm the underlying buffer contains at least one NUL byte, if possible to be confirmed: This is done by the constructors. -> Avoid repeated traversals for strlen: Cache the length. -> Don't calculate the length, if not needed. Only do it at first use. Should be as efficient as a char* pointer (at least regarding the operations).   The confirmation of NUL is not always possible or needs different pre-conditions or different effort:  - constructing from char*: We don't know the length of the buffer. Confirmation not possible.  - constructing from char*+size of buffer: Can be done in O(n)  - constructing from types with guaranteed NUL at the end, but possible intermediate NUL bytes: Already confirmed by type.   -----Ursprüngliche Nachricht----- Von:David Brown via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 05.02.2026 09:06 Betreff:Re: [std-proposals] [Idea] Null-terminated string view (c_str_view / c_wstr_view) – a simpler alternative/complement to zstring_view An:std-proposals_at_[hidden]; CC:David Brown <david.brown_at_[hidden]>; On 04/02/2026 23:41, Ell via Std-Proposals wrote: > On Wednesday, February 4th, 2026 at 10:23 PM, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote: > >> >> >> OK, so there's this API that has a NUL-terminated string inside some >> object or system. And you call a function which retrieves a >> `cstring_view` of that internal string. So... >> >> How would that internal string get embedded NUL characters? >> >> I mean, if the API expects to work with NUL-terminated strings, then >> it probably is going to break if you give it a string with embedded >> NULs. Or at the very least, it will internally truncate the string >> to the first NUL character, since it is internally storing a string >> that is required to be NUL-terminated. >> >> Put simply, if you're dealing with a NUL-terminated string-based >> interface, then the string view you get back should respect that >> behavior. This API shouldn't have a problem with returning a >> `cstring_view` that truncates the string's length to the first NUL >> character, since that is precisely what it did internally when storing >> that string. >> >> So I don't see how having the size be correct for `strlen` instead of >> respecting the size it is given is a problem here. > > > The problem isn't not respecting the size, it's deciding what the > implications of saying that cstring_view can't have embedded nulls are > in practice. I don't think that doing a strlen everywhere is the answer > (or rather, I think that'll make cstring_view pretty useless). > I know using strlen everywhere feels inefficient - it sounds like a lot of extra work for the processor.  As a microcontroller programmer and ex assembly programmer, I dislike such inefficiencies.  But is it really bad in practice?  For one thing, compilers can sometimes cache the results of strlen and reuse it.  When it actually needs to executed, it is a fast inline loop in most implementations.  On modern systems, the speed of it is almost entirely dependent on whether the target data is in near cache or not - if it is not, then the time spent on strlen will be time saved when the API function uses the cstring data.  And if the API you are passing the cstring to is showing it on the screen, or writing it to a file, that API will take thousands of times the effort of the strlen.  Correctness beats speed, and the speed cost is actually a drop in the ocean here. > You deal with it the same way you deal with std::string allowing > embedded nulls. You validate untrusted input, and then you probably > assume there are none. And if your string does have unexpected embedded > nulls then you already have a problem, truncating is just papering over > it. > That part is true enough.  Ideally, however, you'd want different types for validated and unvalidated data - that's your best protection against forgetting to check.  But that is perhaps a different topic. And in view of dealing with potentially unvalidated data, it would be nice if the C++ standard had "strnlen" here rather than just "strlen". -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals