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,b30bd69fa8f63cb2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-16 18:58:06 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed!lon-transit.news.telstra.net!news.telstra.net!news-server.bigpond.net.au!not-for-mail From: Dale Stanbrough Newsgroups: comp.lang.ada Subject: Re: Replacement for Text_IO? (was Re: C bug of the day) References: <1054751321.434656@master.nyc.kbcfp.com> <20030611114948.00000bcc._elh_@_terma_._com_> <20030611125000.000018b5._elh_@_terma_._com_> <3EEE464A.D48A8E2D@somewhere.nil> User-Agent: MT-NewsWatcher/3.3b1 (PPC Mac OS X) Message-ID: Date: Tue, 17 Jun 2003 01:56:48 GMT NNTP-Posting-Host: 144.132.47.50 X-Complaints-To: abuse@bigpond.net.au X-Trace: news-server.bigpond.net.au 1055815008 144.132.47.50 (Tue, 17 Jun 2003 11:56:48 EST) NNTP-Posting-Date: Tue, 17 Jun 2003 11:56:48 EST Organization: BigPond Internet Services (http://www.bigpond.net.au) Xref: archiver1.google.com comp.lang.ada:39304 Date: 2003-06-17T01:56:48+00:00 List-Id: Gautier Write-only wrote: > Dale Stanbrough: > > > Everyone laments the slowness of Text_IO, > > Who ? Who ? Are you an owl? I'm sure one "who?" would do. Ok, it was a bit of hyperbole. -I- don't like the slowness of Text_IO :-) Robert Dewar at one point noted that the presence of these extra "features" prevents certain optimisations in the coding from taking place. One quote from him... "Text_IO is convenient for small scale or occasional use for small amounts of formatted output (compare it to ACCEPT and DISPLAY use in COBOL). It is not the appropriate interface for large scale I/O where performance is critical." try also... http://groups.google.com.au/groups?q=robert+dewar+text_io+efficiency+grou p:comp.lang.ada&hl=en&lr=&ie=UTF-8&group=comp.lang.ada&selm=3id0ip%24e42% 40gnat.cs.nyu.edu&rnum=2 Why not -make- it suitable for large scale I/O? Why not ensure that everyone who wants to do some I/O doesn't have the thought in the back of their head "shouldn't really use text_io because it doesn't scale". > Are you sure that *this* takes much time ? Did you do a profiling ? No, but I believe what Robert Dewar said. It makes me hesitant to recommend people code with Text_IO, which is problematic. It should be possible to have one I/O package which is good, and people feel will be able to grow with their application. > > as well as moving the generic I/O packages into child packages. > > It is an aesthetic issue (although, who cares ?), not a performance > one... Do such non-instanciated generic sub-packages even appear in > the machine-code in object files, on any compilation system ? See Randy's followup. I didn't realise it was a problem efficieny wise, but i've always found it an annoyance when teaching Ada to students. It's much easier to talk about child packages than encapsulated packages. Dale