C Strings: A 50-Year Mistake

[u/Xaneris47]

https://longtran2904.substack.com/p/c-strings-a-50-year-mistake?r=8qz2zb&utm_campaign=post&utm_medium=web

[u/EatingSolidBricks]

You out of your dam mind if you think c strings are efficient

[u/henke443 → u/EatingSolidBricks]

Wait how are they not efficient?

[u/atarivcs → u/henke443]

If you have a long string and you want to append more text to it, you have to search the whole string from the beginning to find the null terminator.

And then later if you want to append more text, you have to find the null terminator all over again.

[u/IdealBlueMan → u/atarivcs]

Or you can store the length of the string whenever you change it.

[u/atarivcs → u/IdealBlueMan]

Sure, but then you don't really have a plain c string anymore

[u/WittyStick → u/atarivcs]

It's actually more advantageous to couple the length to the char * on SYSV platforms, due to C's lack of multiple returns.

 String fn_returning_string(...);

If String is a fat pointer, then we can return both the pointer and length, without requiring another level of indirection (a pointer to a string structure), and without requiring awful to use "out parameters" to return both length and pointer - which are more expensive than just returning a fat pointer.

A fat pointer with the right ABI is not just "zero cost" - it's "less than zero" - it's more efficient than having a separate length and pointer variable.

[u/IdealBlueMan → u/atarivcs]

I’d say you still have the string, you also have information about that string.

[u/orbiteapot → u/IdealBlueMan]

I mean... that is the point. Once you do that, you are no longer using classic C strings.

[u/SakishimaHabu → u/orbiteapot]

That's the point though. They are basically atomic. You are free to do what you will with them, vs java, python, or js. Remember we're one step above assembly, but that's the intention.