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 15:05:21 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Replacement for Text_IO? (was Re: C bug of the day) Date: Mon, 16 Jun 2003 17:06:39 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <1054751321.434656@master.nyc.kbcfp.com> <20030611114948.00000bcc._elh_@_terma_._com_> <20030611125000.000018b5._elh_@_terma_._com_> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:39288 Date: 2003-06-16T17:06:39-05:00 List-Id: Dale Stanbrough wrote in message ... >In article , > "Randy Brukardt" wrote: > >> Even the MS-DOS version (full Ada 83) has quite limited compilation >> sizes because of 640K doesn't go that far. (Text_IO uses about 65% of >> the available memory.) > > >Everyone laments the slowness of Text_IO, and how it isn't a really >high powered I/O solution, yet it is used a lot because it is >reliably there in every Ada compiler. > >Are there any moves to provide an alternative to Text_IO in Ada0Y >that will allow for more efficient implementations? >You could get rid of the Page, Line and Column counting, as >well as moving the generic I/O packages into child packages. Well, we actually have a cut-down Text_IO called RRText_IO in our compilers for this reason. It helped in three ways: 1) It took up less symbol table space; 2) It didn't drag in floating point and tasking support; 3) It didn't have a lot of unused subprograms. Everyone these days has a computer big enough to compile a hundred Text_IOs at once, so (1) isn't needed anymore. Many Ada compilers can eliminate unused subprograms from the final executable, so (3) isn't a real issue, either. (And, for those compilers that can't remove unused subprograms, clearly their implementor's time would be far better spent adding that feature than implementing a new version of Text_IO). (2) is specific to Janus/Ada; I doubt most other compilers can even generate a program without any floating point support. Similarly, Janus/Ada has a tasking stub for non-tasking programs, so that generics work without dragging in the 40K task supervisor. But in the absense of such a feature, it doesn't matter anyway. So I doubt that there would be much benefit to having Text_IO_Lite. The effort probably would be better spent on components or sockets or the like. Randy.