* Re: bashing someone else's string package
@ 1993-09-07 17:53 Wes Groleau x1240 C73-8
0 siblings, 0 replies; only message in thread
From: Wes Groleau x1240 C73-8 @ 1993-09-07 17:53 UTC (permalink / raw)
In article <1993Sep2.174507.9699@cfmu.eurocontrol.be> stef@cfmu.eurocontrol.be
(Stef Van Vlierberghe) writes:
>In article <CBLyxC.64x@crdnns.crd.ge.com> groleau@e7sa.crd.ge.com (Wes
>Groleau x1240 C73-8) writes:
>> P.S. I have seen several "free" variable string packages that have
>> what is to me a RIDICULOUS usage of access types, requiring all sorts
>> of contortions by client packages to avoid dangling pointers and heap
>> exhaustion. [Both] my package and the ones I'm complaining about make th
e
>> type private. [But mine takes advantage of the automatic deallocation when
>> leaving scope.]
>Wes, I believe that introducing an arbitrary limit is perfectly o.k.
>in many situations, but it's just a technique that (in practice) won't
>scale up. If, rather than a simple string, you are implementing a
>multi-file screen editor, you might want a list of buffers, each
>buffer is a list of lines and each line is a list of characters.
Well, yes for something like file management, editing, etc. my string package
would be inappropriate. But as a replacment for type STANDARD.STRING, which
the packages I was objecting to claim to be, these packages are in my
admittedly biased opinion absurd.
I don't think I'd even use them for files/editors. When I had a performance
problem with TEXT_IO in a particular situation, I created a series of types
to implement files as fixed-length arrays of pages, which were fixed-length
arrays of lines, which were STRINGs. Only I used pointers instead of the
actual objects, so they could have easily been variable, and the actual
"file_type" didn't blow up anyone's stack-frame limit. This never caused a
problem until someone did exceed what we thought was a ridiculously high limit
to lines-per-page. (Which limit was easily raised.) If I was going to use it
for output or editing I would have used (theoretically unlimited) linked lists
instead of arrays (which must have SOME limit). But to stop rambling and get
to the point, if you wanted to write an editor, wouldn't you design an
appropriate data structure, instead of trying to extend one that wasn't
even well-suited for its advertised purpose?
Wes G.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~1993-09-07 17:53 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1993-09-07 17:53 bashing someone else's string package Wes Groleau x1240 C73-8
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox