|Pascal vs C style string ? guerin@IRO.UMontreal.CA (1994-06-24)|
|Pascal vs C style string ? email@example.com (1994-06-26)|
|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)|
|Re: Pascal vs C style string ? firstname.lastname@example.org (1994-06-27)|
|Re: Pascal vs C style string ? email@example.com (1994-06-28)|
|Re: Pascal vs C style string ? firstname.lastname@example.org (Stefan Monnier) (1994-06-28)|
|Re: Pascal vs C style string ? email@example.com (Erkki Ruohtula) (1994-06-28)|
|[11 later articles]|
|From:||firstname.lastname@example.org (Joseph H Allen)|
|Keywords:||C, Pascal, design|
|Organization:||The World Public Access UNIX, Brookline, MA|
|Date:||Mon, 27 Jun 1994 05:41:11 GMT|
> Is there some reasons to use string0 over length attributed string ??
email@example.com (Steve Simmons) writes:
>[the length of counted strings is limited by the size of the count field]
If you define the size of the length to be log2 of the size of the address
space (or on the 8086, the segment size), then you never have a problem.
Of course, the language should provide an integer type which is equal to
this size ('int' is this type in C except for on the DEC Alpha).
The only real advantage of 0-terminated strings over length-attributed
strings is that a 0-terminated string plus an offset is still a valid
0-terminated string. (I.E., in C: "Hello" is a valid string and "Hello"+3
is also a valid string).
I occasionally use an elaborate auto-resizing string library for C. It
stores strings as follows: <malloc-block size><string-length><string><0>.
The base address of the string starts at <string>, the string is zero
terminated, and the type is still (char *). This way they are compatible
with existing C code. When you write or concatenate to a string through
the library routines, it will be automatically realloced if it runs out of
space. They are kind of magical though, since a string's length is in
*((int *)string-1) and the malloc block size and start are at ((int
*)string-2). Also, although a string plus an offset is still a valid C
string, it's not a valid auto-resizing string.
Nearly all string operations go through a single function:
char *ncpy(char *string,int offset,char *blk,int size);
/* Copy a block of characters 'blk/size' onto an auto-resizing string
* at a specific offset. If 'string' is NULL, a new string is created. If
* 'offset' is past the end of the string, it gets space filled.
* If 'offset'+'size' is past the end of the string, the string is realloced
* and the string's new address is returned.
These macros are used for filling in the arguments string/offset or blk/size:
#define sc(s) (s),sizeof(s)-1
#define sz(s) (s),strlen(s)
#define sv(s) (s),*((int *)(s)-1)
You can use them as follows:
s=ncpy(sv(s),sc("hi")); Append "hi" to 's'
s=ncpy(NULL,0,sz(r)); Convert 'r' into an auto-string
s=ncpy(sv(s),sv(s)); Concatenate s onto itself
s=ncpy(sv(s),&c,1); Append 'c' onto 's'.
and so on.
I've found that the library can be quite useful, especially for complicated
file-name manipulation routines, but I almost never use it. The problem is
that people can't understand my code when I go through a special library, so
I tend to program in unadorned C whenever possible.
/* firstname.lastname@example.org (188.8.131.52) */ /* Joseph H. Allen */
Return to the
Search the comp.compilers archives again.