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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news.karotte.org!news2.arglkargh.de!noris.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Get_Line problem (GNAT bug?) Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1c1gbc5u9cpvp.1wj1zhhn7q86j$.dlg@40tude.net> Date: Thu, 7 Dec 2006 11:22:19 +0100 Message-ID: <1tua3ke1kfoog.1wqou5d9mwtly.dlg@40tude.net> NNTP-Posting-Date: 07 Dec 2006 11:22:19 CET NNTP-Posting-Host: ac8b79e4.newsspool2.arcor-online.net X-Trace: DXC=198R`AR6\4jEB;5>eE0T7mA9EHlD;3Ycb4Fo<]lROoRaFl8W>\BH3YbRjYUQ23?7:oDNcfSJ;bb[eFCTGGVUmh?dN\HXHJ4e80n?hB>9B6 On Thu, 07 Dec 2006 09:26:07 +0100, Maciej Sobczak wrote: > Dmitry A. Kazakov wrote: > >> When End_Of_File meets a CR (Ctrl-M) it cannot know if this CR manifests >> the end of the current line or both the line end and the file end. > > I understand. But then I consider the specs to be broken, see below. :-) No. It is the concept, which is broken. And that wasn't Ada, who broke it, but crippled operating systems like Windows and Unix. In a proper OS the line terminator is not a character. >> The rules of thumb I suppose I and many other Ada programmers are using: >> >> 1. Never ever use End_Of_File with text files; > > This is broken. For me, End_Of_File is a concept that is completely > orthogonal to what the file contains and how it is interpreted. Right, so see above. You need a file system which has EOF state determinable without look ahead. It is not language business. [Though I don't defend End_Of_File. I would simply remove it from Text_IO.] > It is true that it is defined in Text_IO and therefore it might be a > hint that actually EOF is somehow entangled with interpretation of text > markers, but that's not what I would expect. Huh, what did you expect buying Windows? (:-)) >> 2. If you yet use End_Of_File then do it for *each* character of the file; > > I don't see how it might solve this problem - End_Of_File would block > after first anyway. Yes, but then at least you would know what's going on. End_Of_File happened to be lower level (in OSI hierarchy terms) than Get_Line. Mixing levels is asking for trouble. Because End_Of_File drags you into a character-oriented encoding issues, so have to face this in arms. >> 3. As Adam has suggested, End_Error exception is the right design; > > I don't find it to be "right". For me, exception is something that is > unexpected. An error, usually. [...] OK, this is a bit "theological" issue... (:-)) My answer is no. Exception is not an error. It indicates an exceptional state. Note that an exceptional state is a *valid* state. While an error (bug) has no corresponding program state at all. Sure an exception may indicate an error, but this error is *never* one of the program where it is handled. For example, Segmentation Fault is an error of an application, but a valid state for the OS which has spawned that erroneous application and where Segmentation Fault is handled. To summarize: we should distinguish errors (and states) of the problem and solution spaces. Exceptions live in the latter, what you meant does in the former. >> 4. End_Error is not only cleaner and correct, but also more efficient. > > It's not cleaner for me (see above), it is very likely correct (in the > sense that the real solution is broken) and I don't see on what basis it > is expected to be more efficient. :-) This is because you consider it from the C++ stand point. In Ada exceptions are efficient. They are highly recommended for use in place of return codes. This is a *good* design. End_Of_File in your program serves the purpose of return code. What is even worse, from the software design perspective, is that one operation "give me next line" is split into two, so that the side effect of one determines the outcome of another and reverse. It is a very fragile (and wrong) design. Just notice how much efforts it requires to analyse. And what for? To defend a myth, that each loop should have only one exit? Your code didn't managed that either! Neither manages it inputs longer than 99 characters. Do you call it clean? Further, even in C you wouldn't use it either. You probably would turn to fgetc (or even to fread): int Char; // Do we all know that characters are integers? char is just for fun, // real programmers are using int for all datatypes! (:-)) while (EOF != (Char = fgetc (File))) { ... } -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de