Re: Internal Representation of Strings

On Mon, 16 Feb 2009 11:10:15 +0100, Hans-Peter Diettrich
<DrDiettrich1@aol.com> wrote:


>Chris F Clark schrieb:
>
>> The idea of having the length at the end of the string (and perhaps
>> pointing to that end also) has a certain appeal. You can even follow
>> your length field with a max size field to get a good solution for
>> mutable strings with lengths (crude monospaced ascii art below).
>>
>> pointer-------------------V
>> |unused-space|chars....|0|length|max-size|
>> ..^............^-----------+......|
>> ..+-------------------------------+
>
>What's the essential difference vs. having the length and max-size
>information *before* the text?


I was wondering the same thing. :-) BCET uses a string pool header
which contains (among other things) the current size, the max size,
and a backpointer. The current size is just before the data.


  | header + cur size| string data | 0 | Unused data area|


The string descriptor points to the string data. The "0" is not
included in the cur size, but is always present so that any string can
be passed to routines expecting it. (Yuck.)


>I only can see disadvantages with many common string operations, in
>detail with string concatenation or appending characters to such an
>string buffer.
I can see at least 2 problems. a) Accessing the string always
requires additinal calculations. b) Appending to a string will always
require moving the string data.
--
ArarghMail902 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

Return to the comp.compilers page.
Search the comp.compilers archives again.