Because they are easily scanned, 'just keep loading bytes until you find a zero' is easy to code and easy to understand.

Also, if you come in to a comms channel half way within a string you can synchronise by waiting for the next zero and the start processing future information.

Personally, I really prefer C-strings (null-terminated) over Pascal-strings (length byte). For one thing, you're not limited to any arbitrary amount of characters

, and also I think they're faster to work with, ie. "just go on until you hit a 0" is easier than "read 1 byte, then read that many following bytes" (the latter would require an extra helper variable).
The Linux write syscall for instance doesn't use null-terminated strings, and so one of the first things I do is create a wrapper around it that does...

Also, it's handy (if you're on a *nix platform) that you can interface with libc, which does of course use C-strings (and as far as I know, so does most (library)code).

(besides interacting with other code that uses them for no reason)

revolution wrote:

Because they are easily scanned, 'just keep loading bytes until you find a zero' is easy to code and easy to understand.

Isn't

mov ecx,[esi]
rep movsd


Easier then

@@:
mov eax,[esi]
test eax,eax
jz @f
movsd
jmp @b
@@:

???

revolution wrote:

Also, if you come in to a comms channel half way within a string you can synchronise by waiting for the next zero and the start processing future information.

You could just waste one more byte and put a null in front of the length..

Azu wrote:

revolution wrote:

Because they are easily scanned, 'just keep loading bytes until you find a zero' is easy to code and easy to understand.

Isn't

mov ecx,[esi]
rep movsd


Easier then

@@:
mov eax,[esi]
test eax,eax
jz @f
movsd
jmp @b
@@:

???

But you have to remember that most C functions used are scan type functions like printf, so the scanning is made simpler without the need of a loop counter. And things like movsd are completely non-sensical to C programmers.

Isn't it slower since you have to keep iterating through the whole string just to find how long it is?

Azu wrote:

Isn't it slower since you have to keep iterating through the whole string just to find how long it is?

Yes, but it depends upon your usage model. If you are doing many string length calls then a length prefix may be best in your case. If you do mostly scanning and an extra register to hold the length becomes a problem the null termination may be best. But what about a hybrid approach, have both a length prefix and a null terminator.

I don't expect anyone really knows but it doesn't matter if you write your own code, you can do what suits you best.

Probably C started from the old old processor where registers were a limited resource. The extra loop counter may have been a problem?

Performance metrics are very application specific, I doubt that you can find any sensible advice that can work in everyone's situation.

What is your usage model? How many strings are you dealing with each microsecond in your application? How much of the percent processor time will be spent dealing with strings? What string operations do you do mostly?

These are the sort of Q's you need to ask yourself in order to decide what will be the best solution.

Which?

It may also matter whether you want your strings mutable or immutable (like some newer HLLs). If you eg add to your string, you have to go back to the length byte/word and change that. With a null-terminated string, your algorithms/functions don't change, it's still "keep going until 0".

Azu wrote:

Which?

Only you can know the answer to that. You have to define your usage model first. Even simple things like the average length of strings will affect the answer.

This just occurred to me: performance-wise, if you calculate the length of a C-string once, the entire string will be in your (L1) cache, so future operations on the string could be sped up. Is this a real advantage, or am I just onto nothing here?

Doesn't it take just as much work to write a 0 to the end as it does to write a number to the beginning?

Quote:

Doesn't it take just as much work to write a 0 to the end as it does to write a number to the beginning?

No, with Pascal-strings you have to write in two places: behind the original string, and before it to the length byte, and with C-strings you only write the part behind the original string.

Now, with Pascal-strings you could build in more safety with accessing the string like an array, because you could check the subscript with the length byte (ie, string[10] is allowed only if length(string) >= 10 if you count your subscripts from 1, which is I believe the Pascal-way). But since C has always been about speed and control, and not so much safety, I would guess that the C inventors chose the null-terminated string for those reasons (though I have no literature at hand to back that up).