Path: utzoo!mnetor!uunet!nuchat!sugar!peter
From: peter@sugar.UUCP (Peter da Silva)
Newsgroups: comp.arch
Subject: Re: C machine
Message-ID: <1323@sugar.UUCP>
Date: 27 Dec 87 21:33:02 GMT
References: <261@ivory.SanDiego.NCR.COM> <164@sdeggo.UUCP> <3078@phri.UUCP> <554@PT.CS.CMU.EDU>
Organization: Sugar Land UNIX - Houston, TX
Lines: 29
Keywords: nul terminated strings
Summary: FORTH

In article <554@PT.CS.CMU.EDU>, lindsay@K.GP.CS.CMU.EDU (Donald Lindsay) writes:
> There isn't any "right" string representation. But, there are things 
> worth saying.
> 
> Nul terminated strings: useful, simple.
> 
> Length count at front: overhead, but some operations (like concatenation or
> block transfer) become easier.
> 
> Dope vector: (i.e. a pointer to the string, with length count attached to
> the pointer, not to the string): more overhead, but some more operations
> are eased. (Substring can be done in-place, with no moved characters.)

FORTH maintains static strings as a "cell" (byte, word) followed by that
many bytes. Once you start using them, however, they're maintained as dope
vectors on the stack (you convert from one to another with "count"). Some
strings (words read in but not yet interpreted, disk blocks, etc) are also
null terminated because that happens to be a handy way of dealing with them.

Of course FORTH has capabilities for building initialised static data that
would give a Modula-2 programmer nightmares for weeks.

Some strings are even maintained in a simple VM system, and addressed as
a block and offset. This is how the interpreter reads data from disk blocks.
It just lets the VM word "block" convert the block number into addresses
whenever it needs to read another word. Indirection becomes quite simple.
-- 
-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.