CompuServe Messages

Some are more kludgy than others. In fact, built-in strings are often as bad as character arrays, as they share many of the failings. There are, in my experience, two basic types of string implementations; counted strings and terminated strings. C uses terminated strings; a string is a character pointer or array, it's composed of all characters up to the terminating NUL character. It can be any length, but can't contain the NUL character. The other kind is usually implemented in PASCAL and is the counted string, of which BCPL strings are a type. The counted string can contain all characters, and is basically a structure with a count and string field, the string field being an array of characters. Typically, Pascal string implementations are weak in that Pascal doesn't easily support variable sized arrays. So you allocate a string, and it takes up the maximum string length, no matter it's length. It also means that it's easy to find the length, but it probably takes longer to do any manipulation. Some BASICs have this problem. The BCPL problem is that the count field is a BYTE, so strings can't be over 255 characters long. C type strings can be any length, though the length has to be computed. They can very easily be dynamically created by program or statically allocated by compiler, as char * is a much more standard type than a thing like RECORD len : BYTE; str [1..magiclen] : ARRAY OF CHAR; END;. Of course, languages like BASIC tend to have everything built-in, as opposed to C, which has very little built in. BASIC strings, and to a greater degree ICON and SNOBOL strings, are dynamically allocated and transparent to the user. They also tend to be slow, and require some kind of garbage collection. C type strings with the standard C string library aren't dynamic, but it's rather simple to make them so, without changing any existing functions, with the addition of a few allocation, reallocation, and garbage collection functions. I've even seen this done in PASCAL, though not so cleanly. -Dave