|Pascal vs C style string ? guerin@IRO.UMontreal.CA (1994-06-24)|
|Pascal vs C style string ? firstname.lastname@example.org (1994-06-26)|
|Re: Pascal vs C style string ? email@example.com (1994-06-27)|
|Re: Pascal vs C style string ? firstname.lastname@example.org (1994-06-27)|
|Re: Pascal vs C style string ? email@example.com (1994-06-27)|
|Re: Pascal vs C style string ? firstname.lastname@example.org (1994-06-27)|
|Re: Pascal vs C style string ? email@example.com (1994-06-27)|
|[14 later articles]|
|Keywords:||C, Pascal, design, question, comment|
|Organization:||Universite de Montreal|
|Date:||Fri, 24 Jun 1994 04:32:45 GMT|
Hello compiler writers,
I know this question is an old one but :
To represent a variable length array of char ( a string ) is it better to
use a NULL terminated string or a length attribute ( of word size ) at the
start of the array ?
Some comments :
I can see at least one useful case where the length attribute comes at
hand. When one wants to concatenate, the memory to allocate is known
immediately, that is, the length() function takes time in O(1) vs O(n) for
string0 . Of course, the concatenation itself takes time O(n) in both
cases, but ... ( n = sizeof the string ).
Is there some reasons to use string0 over length attributed string ??
Maybe for substrings, i.e. a pointer to the middle of a string0 is still a
string0, but not the for the other case. Well, in fact it is not really
true because the second string cannot be deleted from dynamic memory, it
is not a valid dynamic object. But in some cases, this sort of hack can be
Any comments ??
[This has in the past seemed to be largely a religious issue. You can
make mild arguments based on your favorite architecture, e.g. C strings
are null terminated in part because on the PDP-11 you can copy them faster
than you can copy counted strings. On the 8086, copying counted strings
is faster, so I expect that had Thompson and Ritchie started later and had
an 8086 breadboard rather than a PDP-11/20, the string format might well
be different. -John]
Return to the
Search the comp.compilers archives again.