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-Thread: 103376,8de7eedad50552f1 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!newsread.com!newsprint.newsread.com!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Ada bench : count words Date: 23 Mar 2005 17:33:23 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <87vf7n5njs.fsf@code-hal.de> <423f5813$0$9224$9b4e6d93@newsread4.arcor-online.net> <18arnvu705ly4$.1wz6ybz1jt70y$.dlg@40tude.net> <1q9cx4jt7802s.k45m6mcntl87$.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1111617203 8429 192.74.137.71 (23 Mar 2005 22:33:23 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Wed, 23 Mar 2005 22:33:23 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:9850 Date: 2005-03-23T17:33:23-05:00 List-Id: Kilgallen@SpamCop.net (Larry Kilgallen) writes: > In article , Robert A Duff writes: > > > Text_IO is pretty broken, from both a usability perspective and an > > efficiency perspective. I normally avoid it, and use pragma Import on > > the C routines (open, read, etc). Suitably wrapped in a clean > > interface, of course. > > Do those C routines handle line lengths, page lengths, and column > specifications ? No. > If not, perhaps you are looking for something different from the full > feature set of Text_IO. Yes, indeed. ;-) For one thing, simple character-by-character (buffered) input is inefficient using Text_IO. I don't usually want to do line-by-line input, but when I do, the features in Text_IO are a pain. Witness the endless series of questions from beginners about that issue in this newsgroup. Another design flaw is that Text_IO mixes I/O with data formatting, which should be treated as two separate issues. > But how Text_IO performs from an efficiency standpoint should depend > upon the particular implementation. Well, in part, but *every* implementation must deal with those column numbers, and that's a waste for applications that don't need it. >... If you have a file system that > does not maintain record boundaries, then Text_IO must do more work. > But _something_ must handle the differences between various text file > formats (Stream-LF, Stream-CR, Stream-CRLF and out-of-band record > breaks). True. It's a shame the computer industry can't standardize on one method. I suspect it's impossible to design a method that is maximally efficient and maximally portable and maximally convenient in this regard. > The C routines with which I am familiar (VMS) seem to force the user > to convert everything into a stream of bytes and then the C routines > convert it back into the actual file format (like those listed above). > _That_ is my idea of inefficient. I'm not a big fan of Record Management Services, by the way. ;-) - Bob