[z92]

Also note that the way he fixed it, strlen only caches the last call and returns quickly on an immediate second call with the same string.

Another reason why C styled null terminated strings suck. Use a class or structure and store both the string pointer and its length.

I have seen other programs where strlen was gobbling up 95% of execution time.

[wruza]

Not that C strings do not suck, but with pascal strings we could discuss in this thread how implicitly copying a slowly decreasing part of a 10mb string at every tokenizer iteration could miss a developer’s attention. It’s completely unrelated to C strings and is completely related to bytefucking by hand. Once you throw a task like “write a low-level edge-case riddled primitive value shuffling machine” into an usual middle level corporative production pipeline, you’re screwed by default.

[ziml77]

I'm with you. I hate null terminated strings. In my first experiences with C, I specifically hated them because of strlen needing to scan them fully. When C++ introduced string_view, my hate grew when I realized that I could have zero-copy slices all the way up until I needed to interface with a C API. At that point you're forced to copy, even if your string_view came from something that was null terminated!

[ip26]

Could this be worked into a compiler/stdlib from the back-end? Could a compiler/stdlib quietly treat all strings as a struct of {length,string} and redefine strlen to just fetch the length field? Perhaps setting a hook to transparently update "length" when "string" is updated is not trivial.

Edit: hah, I'm decades late to the party, here we go:

Most modern libraries replace C strings with a structure containing a 32-bit or larger length value (far more than were ever considered for length-prefixed strings), and often add another pointer, a reference count, and even a NUL to speed up conversion back to a C string. Memory is far larger now, such that if the addition of 3 (or 16, or more) bytes to each string is a real problem the software will have to be dealing with so many small strings that some other storage method will save even more memory (for instance there may be so many duplicates that a hash table will use less memory). Examples include the C++ Standard Template Library std::string...

https://en.wikipedia.org/wiki/Null-terminated_string

[toast0]

I don't think you could do it transparently, because it's expected to pass the tail of a character array by doing &s[100] or s + 100, etc. I don't think that would be easy to catch all of those and turn them into a string fragment reference.

From c++ class, std::string was easy enough to use everywhere, and just foo.c_str() when you needed to send it to a C library. But that may drags in a lot of assumptions about memory allocation and what not. Clearly, we don't want to allocate when taking 6 minutes to parse 10 megs of JSON! :)

[magicalhippo]

If only C had introduced an actual string type...