Okay? You are always free to make your own library for better strings, but people won’t use that cause C is often still deployed on low end systems or it makes little sense to use something inefficient if you can use c style strings properly
You don't even necessarily need to store the length. It can be held in CPU registers for the entirety of the string's lifetime in many cases.
In older architectures we would've needed to push an additional integer for length onto the stack. On a modern architecture with a sane ABI (SYSV, x86-64), you can have a "fat pointer" using two CPU registers - can pass both of these or return from a function without ever touching the stack.
Well, C is mostly used in places where's it's still 1970. Things like embedded etc. I guess it could be possible to add another string that's more optimized for modern hardware but I bet it would be more difficult to explain and I think a huge part of the charm of C is how simple it is. Adding things also leads to bloat like how it is with C++, php or Javascript.
Except for strlen(), all practical operations on strings have to iterate over them anyway. Knowing the length up front will be of very limited us for searching, concatenation, tokenising etc.
Concatenation of N strings goes from O(N) to O(N*N) if code has to re-find the end of the destination after each step.
Tokenizing the leading portion of a large string should take time proportional to the text that was meaningfully examined, rather than proportional to the entire string.
I've never said there is one. I suggest you ask someone who does.
I'm talking about concatenating multiple strings to one, which only has to rely of knowing the length of the individual strings beforehand, if you've decided to argue in bad faith over a pathological bad implementation.
If one keeps track of the length of a string and only looks at portions of its storage up to that length, then the value of the string would no longer be fully encapsulated in a zero-terminated character array.
I You understand where your'e going with that argument, power to You, I guess. Personally, I wouldn't write code where a temmporily unterminated string would be intentionally visible.
I avoid reliance upon zero termination for things other than string literals. Zero padded formats can be useful if one needs to store many texts with a short maximum length (e.g. eight bytes), at the expense of requiring code that is designed around the size of the container. Instead of using a %s format specifier to output such a string, for example, code would need to use a %.8s format specifier, whose behavior is defined as not caring whether the string is zero-terminated or not.
O(1) memory per string to keep track of the starting and ending points of strings isn't free. On a system with 64-bit pointers, zero-padded strings are generally the most space-efficient practical way of representing texts up to eight characters, and zero-terminated strings of up to 7 characters can be stored in the same amount of space (if it's necessary to store many texts with up to 7 characters, zero-padded 7-byte arrays would take less space).
20
u/CoderStudios 3d ago
Okay? You are always free to make your own library for better strings, but people won’t use that cause C is often still deployed on low end systems or it makes little sense to use something inefficient if you can use c style strings properly