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,5afe598156615c8b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Thu, 07 Dec 2006 18:12:47 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <1c1gbc5u9cpvp.1wj1zhhn7q86j$.dlg@40tude.net> <1tua3ke1kfoog.1wqou5d9mwtly.dlg@40tude.net> Subject: Re: Get_Line problem (GNAT bug?) Date: Thu, 7 Dec 2006 18:13:41 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-7V9dRMcASu6XkdzqtMyMLZgLghY8G0BvOs54jPBfbIsO7c/9mZ+m/kOql4vnfq1zJWiBGQ9U72DEW8R!AJL20LpZZ5gdbhjAdVaNVwfjPihBAHmouUXxXP5CvWIFG4elZ/i8X51MeYkVZFPsQQECYZGzlixS!5kIIyWo06uyBdQ== X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:7860 Date: 2006-12-07T18:13:41-06:00 List-Id: "Robert A Duff" wrote in message news:wccfybrtj5h.fsf@shell01.TheWorld.com... > Note: I don't know of any Ada compiler that uses Text_IO to read the Ada > source code to be compiled. Janus/Ada did originally, back in the early days when we had a partial implementation of everything. Once we finished the complete Text_IO, though, the whole thing became too slow. Indeed, these days all of the compiler's IO is done directly through the lowest of our I/O layers (we called it "Basic_IO", it's vaguely like Stream_IO). My two cents on this silly discussion: (1) The definition of End_of_File requires reading ahead as many as 4 characters. End_of_Line similarly requires read-ahead in some cases. This requirement has a significant impact on the entire Text_IO (once you've read those characters ahead, you have to save them somewhere for future use. But regular buffering would make Standard_Input from the keyboard unusable...). The requirement for lookahead means that it should *never* be called on anything that can't be buffered, like the keyboard. So using End_of_File on Standard_Input is always a mistake. Besides, it doesn't make sense for a keyboard to even have an EOF. Systems that allow it - like UNIX - are more likely to cause problems because of an accidental EOF than any possible use. Way back, we had a CP/M machine which treated -Z from the keyboard as closing the keyboard - a reboot was required to fix it. The machine actually had a -Z key!! That often caused loss of work when the keyboard input to the editor suddenly became closed... End-of-file from Standard_Input is *the* classic example of an exceptional condition that shouldn't clutter the "normal" code. (2) The implementation of Text_IO is *very* complicated, especially by things that are hardly ever used like page terminators, and line and page counts. Some routines are especially bad; End_of_File is one of these. Because of this substantial overhead, it's usually far more efficient to read a file with an infinite loop terminated by an exception. (3) Text_IO.Get_Line has to read a character at a time. This can be as much as ten times slower than other methods of reading input. So, if performance is critical, it's probably best to read and interpret the file another way. (4) All of this behavior is required by the RM and is enforced by the ACATS. An implementation that doesn't return End_of_File = True for a file containing just a blank line will fail the ACATS. (5) Does this mean that the definition of Text_IO is screwy and over-complex? Absolutely. But there is absolutely no chance that there will be any change in the definition of Ada.Text_IO -- it would break a large percentage of existing Ada programs. So, unless you're designing a replacement language for Ada, there's no point whining about it. The definition of the language is not going to change; compilers are not going to change. Live with it. And that means that for 99% of programs, calling End_of_File is just wrong; handle End_Error instead. Sorry if that hurts your sensibilities. Randy.