From: Stefan Monnier
Subject: Re: allocator and GC locality (was Re: cost of malloc)
Date:
Message-ID: <40up1a$s6q@info.epfl.ch>
In article <···················@slsvhdt.lts.sel.alcatel.de>,
James Kanze US/ESC 60/3/141 #40763 <·····@lts.sel.alcatel.de> wrote:
] 3) it must ``work'' with the old, '\0' terminated C style strings.
] After all, this is what, for example, most window systems will expect
] for a considerable time.
This doesn't look like a big deal to me: just have conversion functions from/to
C-strings to your string representation and you're set. Of course, you don't
want to suffer from C's brain damage too much, so you should accept strings with
embedded \0, which makes the conversion functions incorrect in the presence of
such embedded \0's. But you can probably get around the problem by providing a
default behaviour (leave the \0's in the string (it's faster since you don't
have to care about the specific problem)) and a way for the user to provide
alternative behaviors (through function parameters or by returning a list of
C-strings).
] I don't see any possibility of passing a file to a ``standard'' string
] class without reading it anyway. Remember, you do not have access to
] the internals of a standard string class to let it know about
] alternative representations, like a file. So if it isn't provided for
] in the standard, you don't have it.
see below...
] I agree here. My own string class did not support inplace updates,
] and I've never really seen the need for them. But a ``standard''
] string class must represent a consensus, and most people seem to want
] inplace updates. (The only non-const function in my string class was
] operator=.)
inplace updates are a pain because they leave a lot less freedom to the
implementor (he cannot share and unshare at will: the user has to know when
things are shared whn they aren't). But see below...
] [I've cut the text concerning scaling. As I said earlier, I'm not
] convinced that the general string class has to support long strings
] that efficiently...]
I can't really understand why you all seem to assume that there should be 1 and
only 1 string class. Of course there should be 1 deferred string class, but
then several implementations.
For instance a FileString class which turns a file into a string without
necessarily reading the whole file at once, but only read it on demand.
A MutableString class (probably a deferred class also with several
implementations) and a way to "copy" a string and get a Mutable vrsion of it.
Stefan