From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,794c64d1f9164710 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-02-22 07:29:26 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!hub1.nntpserver.com!DirecTVinternet!DirecTV-DSL!sn-xit-03!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Matthew Heaney" Newsgroups: comp.lang.ada Subject: Re: functions, packages & characters Date: Fri, 22 Feb 2002 10:34:34 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <20020221130715.12738.00000034@mb-bg.aol.com> <3C753C66.8020509@mail.com> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:20252 Date: 2002-02-22T10:34:34-05:00 List-Id: "Randy Brukardt" wrote in message news:u7bcro6je1h519@corp.supernews.com... > > > loop > > Get_Line (Line, Last); > > Append (Buffer, Line (Line'First .. Last)); > > exit when Last < Line'Last; > > end loop; > > This is, of course, the inefficiency that I was commenting on. No, the inefficiency you were commenting on was the size of the string buffer Line, which you said had to be one. That is wrong -- as in my example, it can be of arbitrary size. > This would be slow, and would cause an awful lot of memory allocation and > deallocation, with the possible exception of the first iteration. Well, the inefficiency of appending to an Unbounded_String is a separate issue. We were talking about the inefficiency of Get_Line. If you don't like Unbounded_String, then use another data structure. > It would only be a good idea if the size of Line was larger than almost all > expected lines. Fine, then declare a large size for Line. I typically use 81 or 133, when reading text from standard input. > (Personally, I never use Unbounded strings, mainly because it took me > years to figure out how to use regular Ada strings effectively, and > Unbounded strings don't buy anything if you are used to doing that.) If Unbounded_String offends you, then use a recursive implementation to return an unconstrained String. Or use another data structure. The point is that of course you can distinguish when you've consumed the entire input line. My example illustrates the standard idiom, per AI-50.