comp.lang.ada
 help / color / mirror / Atom feed
* 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