Related articles |
---|
Pascal vs C style string ? guerin@IRO.UMontreal.CA (1994-06-24) |
Pascal vs C style string ? ssimmons@convex.com (1994-06-26) |
Re: Pascal vs C style string ? prener@watson.ibm.com (1994-06-27) |
Re: Pascal vs C style string ? jhallen@world.std.com (1994-06-27) |
Re: Pascal vs C style string ? ddean@robadome.com (1994-06-27) |
Re: Pascal vs C style string ? boehm@parc.xerox.com (1994-06-27) |
Re: Pascal vs C style string ? nandu@cs.clemson.edu (1994-06-27) |
Re: Pascal vs C style string ? eifrig@beanworld.cs.jhu.edu (1994-06-28) |
Re: Pascal vs C style string ? monnier@di.epfl.ch (Stefan Monnier) (1994-06-28) |
Re: Pascal vs C style string ? eru@tele.nokia.fi (Erkki Ruohtula) (1994-06-28) |
Re: Pascal vs C style string ? andrew@cee.hw.ac.uk (1994-06-28) |
Re: Pascal vs C style string ? jhallen@world.std.com (1994-06-28) |
[9 later articles] |
Newsgroups: | comp.compilers |
From: | boehm@parc.xerox.com (Hans Boehm) |
Keywords: | C, Pascal, design |
Organization: | Xerox Palo Alto Research Center |
References: | 94-06-175 |
Date: | Mon, 27 Jun 1994 19:30:35 GMT |
You might also want to look at the "cord" string package that's included
with the garbage collector in parcftp.xerox.com:pub/gc/gc.tar.Z. It has
the following characteristics:
1) Concatenation takes unit time independent of the length of the strings
being concatenated.
2) Strings may be described by a function for generating the i'th
character. (E.g. a function is provided for turning a read-only file
into a string such that the file is read lazily. A toy editor that uses
this for editing huge files is also included.)
3) The substring operation takes time roughly logarithmic in the length
of the original string.
4) A string can be traversed in linear time (though the constant is a
bit worse than for C strings).
5) Nonenmpty C strings may be used directly as "cord"s. (Building large
strings this way will invalidate (1).)
The package is based loosely on Cedar "Ropes". (The current description
in the .h file makes it a little difficult to identify the important
parts of the interface. That'll be fixed in the next version.)
Hans-J. Boehm
(boehm@parc.xerox.com)
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.