In article <··········@info.epfl.ch> "Stefan Monnier"
<··············@epfl.ch> writes:
|> 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 sort of agree. Still, the string class will have to manage the
memory for the flat representation as well.
Embedded '\0' aren't really a problem; if the string is appropriate
for passing to the C functions, it won't have any:-). And if it is
not appropriate, who cares.
|> ] 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.
Actually, this thread started because I argued that you need
specialized string classes, so there was no real point in ensuring
that the ``standard'' string class was optimal (from a run-time point
of view).
--
James Kanze Tel.: (+33) 88 14 49 00 email: ·····@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
-- Beratung in industrieller Datenverarbeitung
From: Stefan Monnier
Subject: Re: allocator and GC locality (was Re: cost of malloc)
Date:
Message-ID: <40vgu4$73r@info.epfl.ch>
In article <···················@slsvhdt.lts.sel.alcatel.de>,
James Kanze US/ESC 60/3/141 #40763 <·····@lts.sel.alcatel.de> wrote:
] I sort of agree. Still, the string class will have to manage the
] memory for the flat representation as well.
Big deal: malloc the thing, return the pointer and document the fact that
whenever the string is not useful any more, it has to be freed by "delete".
Stefan