Alex.Brown@f1020.n391.z1.FidoNet.Org (Alex Brown) (05/31/91)
I am getting an overflow error after 3 pages are displayed. Can
any tell
why and how to avoid it in the future.
The program is supposed to grab 24 lines of a text and display them
with a
>>>>>>>MORE<<<<<<<< message at the bottom.
Program View;
uses dos, crt;
var
ftext : text;
f : integer;
s : array[1..25] of string;
procedure showpage;
begin
f := 1;
while f < 25 do
begin
writeln(s[f]);
inc(f);
end;
end;
procedure getstring;
begin
f := 1;
while (not eof(ftext)) and (f < 25) do
begin
readln(ftext, s[f]);
inc(f);
end;
if not eof(ftext) then
begin
s[25] := ' >>>>>>>>MORE<<<<<<<< ';
showpage;
readln;
end;
getstring;
end;
begin
if paramcount <> 1 then
begin
writeln('Syntax is VIEW "filename" ');
halt;
end;
assign(ftext,paramstr(1));
reset(ftext);
getstring;
close(ftext);
end.
---
* Origin: The Ozark Connection/Fayetteville, AR * (1:391/1020)
dvlhma@cs.umu.se (Henrik Magnusson) (05/31/91)
In article <675648024.0@nwark.FidoNet> Alex.Brown@f1020.n391.z1.FidoNet.Org (Alex Brown) writes: > > I am getting an overflow error after 3 pages are displayed. Can >any tell >why and how to avoid it in the future. > > The program is supposed to grab 24 lines of a text and display them >with a > >>>>>>>MORE<<<<<<<< message at the bottom. [deleted text.] >procedure getstring; > begin > f := 1; > while (not eof(ftext)) and (f < 25) do > begin > readln(ftext, s[f]); > inc(f); > end; > if not eof(ftext) then > begin > s[25] := ' >>>>>>>>MORE<<<<<<<< '; > showpage; > readln; > end; > getstring; > end; > When you are using getstring recurively, you must have a basecondition. Which means you must check if the recursion should stop. I would write getstring like this: PROCEDURE GetString; BEGIN IF (NOT EOF(ftext)) THEN BEGIN : your code here : END END; /NeNNe ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: Henrik Magnusson :: "How'd you puncture that tyre?" :: :: dvlhma@cs.umu.se :: "Ran over a milk bottle" :: :: :: "Didn't you see it?" :: :: Umeaa University, Sweden :: "Damn kid had it under his coat." :: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
acm@Sun.COM (Andrew MacRae) (05/31/91)
In article <675648024.0@nwark.FidoNet>, Alex.Brown@f1020.n391.z1.FidoNet.Org (Alex Brown) writes: > > I am getting an overflow error after 3 pages are displayed. Can > any tell > why and how to avoid it in the future. The problem is that you are calling the procedure getstring recursivly (that is from within the procedure itself). Rather than have that call to getstring at the end of getstring, try using (yet another) WHILE loop testing for eof outside the scope of the loop that is testing for eof and f < 25. The reason I say 'yet another WHILE loop' is that you should learn how to use the FOR loop. Your code in the procedure showpage that sets f to 1, then loops while incrementing f and testing for completion is in essence a FOR loop. You are also going to run into problems of an interesting nature when displaying the last page of a file, but I will let you discover how. (It's a problem I remember running into myself.) Andrew MacRae > > The program is supposed to grab 24 lines of a text and display them > with a > >>>>>>>MORE<<<<<<<< message at the bottom. > > > Program View; > uses dos, crt; > > var > ftext : text; > f : integer; > s : array[1..25] of string; > > procedure showpage; > begin > f := 1; > while f < 25 do > begin > writeln(s[f]); > inc(f); > end; > end; > > > procedure getstring; > begin > f := 1; > while (not eof(ftext)) and (f < 25) do > begin > readln(ftext, s[f]); > inc(f); > end; > if not eof(ftext) then > begin > s[25] := ' >>>>>>>>MORE<<<<<<<< '; > showpage; > readln; > end; > getstring; > end; SUGGESTED: Procedure getstring; Begin While not EOF(ftext) do Begin f := 1; While (not EOF(ftext)) and (f < 25) do Begin ReadLn(ftext, s[f]); Inc(f) End; If not Eof(ftext) Then Begin s[25] := ' >>>>>>>>MORE<<<<<<<< '; showpage; ReadLn End End End; > > begin > if paramcount <> 1 then > begin > writeln('Syntax is VIEW "filename" '); > halt; > end; > assign(ftext,paramstr(1)); > > reset(ftext); > getstring; > close(ftext); > end.
chris.chambers@rose.uucp (CHRIS CHAMBERS) (06/02/91)
From: chris.chambers@rose.uucp (Chris Chambers) Subj: Overflow error Alex Brown writes: AB> I am getting an overflow error after 3 pages are displayed. Alex, the overflow error occurs when you have read all the records from the file. You program is not coded to exit the GetString routine after the last record has been read. AB> reset(ftext); AB> getstring; AB> close(ftext); Change the second line to: repeat getstring until eof(ftext); Alex also writes: AB> The program is supposed to grab 24 lines of a text and display them AB> with a AB> >>>>>>>MORE<<<<<<<< message at the bottom. In your ShowPage procedure you do not perform the loop enough times to get this message displayed. You also need to change the logic in GetString and ShowPage to handle the variable number of lines to be displayed on the last page. I have not posted the corrected code, but sufficient pointers to get get your going. It's no fun for you if you got the canned answer, and you would not learn that way. ---
cslaurie@cybaswan.UUCP (Laurie Moseley ) (06/16/91)
Surely any file-reading should be done in a WHILE NOT EOF loop, rather than a REPEAT UNTIL EOF one. The whole point of the WHILE is that it may be entered zero times, and therefore you are automatically guarding against the danger of trying to read from an empty file. In general the use of WHILE for the traversal of many structures (queues stacks etc) is good practice anyway, as it removes at a stroke the need for a lot of special case checking, such as testing for nil pointers. I reserve the use of REPEAT UNTIL for cases where I know that the loop will be entered at least once - keyboard input data checking for example, or a sort routine. It was invented only for convenience after all, and can be emulated by a WHILE. What's all this stuff about GETSTRING; - a parameter-less procedure. OK, there may be occasions when you need one, but they are rare in these days when one actually re-uses code. I don't believe that it is purist to shudder at such constructions, it's simply commonsense. You may get away with parameter-less procedures occasionally, but all too frequently one of two things will happen. You'll either get identifier confusion and manipulate a global unintentionally (and have some interesting evenings trying to find that !) or you will find that you have written the same procedure 7 times before you realise that it IS the same one. I guess that the point is that if you get into good habits early, you have fewer disasters later. To put on the humility hat for a moment - am I missing something important here ? Laurie ========================================================================== Laurie Moseley Computer Science, University College, Swansea SA2 8PP, UK Tel: +44 792 295399 JANET: cslaurie@uk.ac.swan.pyr ========================================================================= "Why does the Turing test set such abysmally low standards ?" ===========================================================================
milne@ics.uci.edu (Alastair Milne) (06/16/91)
In <2547@cybaswan.UUCP> cslaurie@cybaswan.UUCP (Laurie Moseley ) writes: >Surely any file-reading should be done in a WHILE NOT EOF loop, >rather than a REPEAT UNTIL EOF one. The whole point of the WHILE is >that it may be entered zero times, and therefore you are automatically >guarding against the danger of trying to read from an empty file. In >general the use of WHILE for the traversal of many structures (queues >stacks etc) is good practice anyway, as it removes at a stroke the >need for a lot of special case checking, such as testing for nil pointers. Unfortunately, the scanning of lists or other graphs is not quite as simple as that, but it's a good point that for cases where the loop may never run at all, WHILE is to be preferred. But since we seldom work with empty files, it often takes a moment's thought to remember that it can happen. >I reserve the use of REPEAT UNTIL for cases where I know that the loop >will be entered at least once - keyboard input data checking for >example, or a sort routine. It was invented only for convenience >after all, and can be emulated by a WHILE. I disagree that it was invented for convenience. Rather, it was invented for cases where the semantics of the WHILE loop obscure the fact that the loop must run at least once. How often have we seen such constructs as this:? Done := TRUE; WHILE NOT Done DO BEGIN ... END; which, once you realise what to look for, are begging for conversion into a REPEAT. With cases like this taken into account, I find I use many more REPEATs than WHILEs. [observations about parameterless routines and use of globals deleted -- I agreed with them all anyway!] Alastair Milne
CDCKAB%EMUVM1.BITNET@cunyvm.cuny.edu ( Karl Brendel) (06/19/91)
In <2547@cybaswan.UUCP> cslaurie@cybaswan.uucp (Laurie Moseley) wrote: [...deleted...] >What's all this stuff about GETSTRING; - a parameter-less procedure. >OK, there may be occasions when you need one, but they are rare in >these days when one actually re-uses code. I don't believe that it >is purist to shudder at such constructions, it's simply commonsense. >You may get away with parameter-less procedures occasionally, but >all too frequently one of two things will happen. You'll either get >identifier confusion and manipulate a global unintentionally (and >have some interesting evenings trying to find that !) or you will >find that you have written the same procedure 7 times before you >realise that it IS the same one. > >I guess that the point is that if you get into good habits early, >you have fewer disasters later. To put on the humility hat for a >moment - am I missing something important here ? Perhaps. While I agree with most of the points that you have made so well, I must speak up in defense of "parameter-less procedures". Procedures are not only a means to the creation of reusable code, but a means of organizing source so that it becomes more readable and even (yes) more maintainable. There are others who also _may_ not be purists (as if that were always an objectionable state of being <g>) who would prefer to see every routine fit on one screen or possibly one sheet of hardcopy. I am not advocating that extreme--but I find that I can read and maintain code much more easily if routines are smaller and carry mnemonic names--and I don't feel the need of forcing each routine to have parameters in order to accomodate that. Cheers-- --Karl +====================================================================+ | Karl Brendel Centers for Disease Control | | Internet: CDCKAB@EMUVM1.BITNET Epidemiology Program Office | | Bitnet: CDCKAB@EMUVM1 Atlanta GA 30333 USA | | Home of Epi Info 5.0 | +====================================================================+
bobb@vice.ICO.TEK.COM (Bob Beauchaine) (06/19/91)
In <2547@cybaswan.UUCP> cslaurie@cybaswan.uucp (Laurie Moseley) wrote: >What's all this stuff about GETSTRING; - a parameter-less procedure. >OK, there may be occasions when you need one, but they are rare in >these days when one actually re-uses code. I don't believe that it >is purist to shudder at such constructions, it's simply commonsense. >You may get away with parameter-less procedures occasionally, but >all too frequently one of two things will happen. You'll either get >identifier confusion and manipulate a global unintentionally (and >have some interesting evenings trying to find that !) or you will >find that you have written the same procedure 7 times before you >realise that it IS the same one. > >I guess that the point is that if you get into good habits early, >you have fewer disasters later. To put on the humility hat for a >moment - am I missing something important here ? { On pulpit } I guess you haven't written any Test and Measurement code (in a while) (ever). I daily write/modify programs with thousands of lines of code that manipulate hardware and test equipment. Parameter-less procedures are the *only* to make some of this code both modular and maintainable, especially since I am not the person sustaining this code x number of years down the road. Many of the mundane tasks and routines performed by this kind of code are very well known in advance. Hooking up ports, initializing equipment, powering up supplies, etc.... You don't need parameters to this kind of procedure, and indeed these procedures keep you from re-writing code dozens of times sprinkled throughout the program. I wouldn't comment, except your second paragraph implies that I do not practice good programming habits. To which I say--- Ack, Phhhttttt. { Off pulpit } /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Bob Beauchaine bobb@vice.ICO.TEK.COM C: The language that combines the power of assembly language with the flexibility of assembly language. God is real, unless declared integer.