Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!nosc!cod!misner From: misner@cod.NOSC.MIL (John Misner) Newsgroups: comp.lang.fortran Subject: Re: Fortran 77 Style Guide (long, REPOST) Summary: In-line FORMATS slow execution Keywords: FORMAT, run-time Message-ID: <2250@cod.NOSC.MIL> Date: 13 Sep 90 22:19:28 GMT References: <62893@lanl.gov> Reply-To: misner@cod.nosc.mil.UUCP (John Misner) Followup-To: comp.lang.fortran Distribution: na Organization: Naval Ocean Systems Center, San Diego Lines: 29 In article <62893@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > > The format specification for an I/O statement should be included > _within_ the I/O statement itself, unless the same format is used > by several different I/O statements. > >So, if a format only applies to one I/O statement, it is _within_ that >statement. If it applies to more than one, it is specified separately. > >J. Giles The problem with this is that some (e.g. UNIVAC and VAX/VMS) compilers do only 0 level checks on the in-line FORMAT - possibly limited to making sure the format is a character variable or, if it is a constant or a character PARAMETER, an additional check that it begins and ends with '(' and ')'. The run-time I/O then is instructed to do a complete parsing of the format *EACH TIME* the statement is executed. Apart from not finding out until run time whether the format is valid, this adds considerable processing (and therefore time) to the execution of the code, even if there are no multiple executions involved. I think (though I dont usually follow my own advice) that all format statements should, for maintainability, be grouped together between the STOP or RETURN statement and the END statement. Most editors also allow you to find out what line you are editing, hop to the nearest END, and then return to the line you were editing. My use of in-line FORMATs is restricted to quick-and-dirty debug I/O. J. Misner