From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 7 Sep 93 17:53:50 GMT
From: news.crd.ge.com!e7sa!groleau@uunet.uu.net  (Wes Groleau x1240 C73-8)
Subject: Re: bashing someone else's string package
Message-ID: <CCzwDq.qC@crdnns.crd.ge.com>
List-Id: <comp.lang.ada>

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.