Newsgroups: comp.lang.dylan,comp.lang.misc,comp.lang.lisp,comp.object,comp.arch,comp.lang.c++
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!yale!zip.eecs.umich.edu!newshost.marcam.com!news.mathworks.com!fu-berlin.de!news.belwue.de!news.uni-stuttgart.de!rz.uni-karlsruhe.de!xlink.net!slsv6bt!news
From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
Subject: Re: allocator and GC locality (was Re: cost of malloc)
In-Reply-To: boehm@parc.xerox.com's message of 9 Aug 1995 16:58:37 GMT
Message-ID: <KANZE.95Aug10145551@slsvhdt.lts.sel.alcatel.de>
Lines: 43
Sender: news@lts.sel.alcatel.de
Organization: SEL
References: <9507261647.AA14556@aruba.apple.com> <3v8g7l$cge@jive.cs.utexas.edu>
	<3vac07$ptf@info.epfl.ch> <3vb382$dtr@jive.cs.utexas.edu>
	<3vbl70$bht@fido.asd.sgi.com> <hbaker-3107951026250001@192.0.2.1>
	<justin-0108951458440001@158.234.26.212> <hbake
	<jyuynr@bmtech.demon.co.uk> <hbaker-0208950816000001@192.0.2.1>
	<jyvgwh@bmtech.demon.co.uk> <hbaker-0408950815320001@192.0.2.1>
	<405k8h$emi@news.parc.xerox.com> <hbaker-0708951241390001@192.0.2.1>
	<40apft$3im@news.parc.xerox.com>
Date: 10 Aug 1995 12:55:51 GMT
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:5035 comp.lang.misc:22611 comp.lang.lisp:18640 comp.object:36621 comp.arch:60314 comp.lang.c++:143187

In article <40apft$3im@news.parc.xerox.com> boehm@parc.xerox.com (Hans
Boehm) writes:

    [Concerning the quality, or lack thereof, of standard string
classes...] 
|> I don't think you should use string manipulation where it's inappropriate.
|> But many programs (editors, mailers, news readers, etc.) naturally
|> manipulate long strings.  Currently they mostly invent their own custom
|> representations, except where the authors decided not to bother.  In those
|> places they effectively break on unexpectedly long input.  Why not use
|> a robust representation as the standard, and then optimize in those
|> few places where it doesn't perform adequately, and it's safe to
|> optimize?

I've considered this a bit, too.  I know of several ways of
implementing a string class that are significantly faster than the
classical solution for specific operations.

The problem is, that the operations which need to be optimized are not
the same for different applications.  A compiler will need different
string handling than an editor, for example.

With this in mind, I'm not really convinced that the solution is to
try and create an optimal string class as a standard.  I rather think
of the standard string class as a facility for people like myself,
whose programs only do string handling secondarily (formatting error
messages, and the like).  If I were writing an editor, for example, I
would not expect the standard string class to be acceptable for my
text buffers.  In this regard, just about any string class with the
required functionality will do the trick.  (And it is more important
that the string class be easier to use than that it be fast.)

This does mean that most text oriented applications will have to
`re-invent the wheel', in that they will have to write their own
string class.  But I'm not convinced that there is a string class
which would be appropriate for all applications, anyway.
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung


