>>32
Because that's when they become useful. Oh, and efficient strings need to be UTF-16 or UTF-32.
if you're working with strings so long you even notice those you're doing something wrong.
That's retarded.
i can write shitty code in python/ruby/haskell/whatever language you think is superior, too.
But when a language provides you with null-terminated strings, you have to go out of your way and do it yourself in order to NOT write shitty code.
>>33
First of all you seem to be comparing a language that was designed as a "high level assembly" of sorts with a modern language with bounds checking and other such niceties. Stop.
If you say C isn't capable of decent strings, then you're bashing C, not me.
The other advantage of a null-delimited string over having an integer specifying how long the string is is that the latter has a maximum length while the former has no such limit.
Be real. How often would you want to use null bytes in strings or to have O(1) length, faster concatenation, better optimizations, etc., versus having strings larger than fucking 4 GB?
Because, y'know, memory/time efficiency is kind of what C is all about
If you're so CFLAGS JUST KICKED IN, YO!-oriented, you'd want O(1) length and faster string operations. Plus -O3 -mword-strings -malign-double would provide you with awesome word-by-word string optimizations! OMG recompile your kernel!
>>32-33
Seriously, why's that? Why are you being such a fag? Are you a C fanboy? This is kind of lame. What advantages would null-terminated strings have? Length and storage space marked strings are much, much better any day for any purpose. The only advantages of null-terminated strings, to save space on tiny strings, and to get past 4 GB length is nothing compared to its huge disadvantages.