----- Original Message -----
From: "Colin Millar" <[log in to unmask]>
> I am relatively new to programming, and my only language is F90.
A good start in programming!
>As I
> understand the backspace function, the current position in the file must
be
> known, say n. And then the file is rewound to its first record, and n-1
> successive reads performed.
That may, or may not, be the way it's implemented. As far as the user is
concerned, you backspace 1 record, or over the end-of-file if that's where
you are positioned ("Fortran 90/95 Explained", Section 10.2.1). The
backspace can be costly.
>So I was wondering if there was an intrinsic
> routine to access the current file position for use later, or would it be
> easier to encase the read statement in a routine with a SAVE attributed
> integer, say count, and use count as an index?
Well, you could do that, but you may want to consider using direct-access
(or indexed) files instead (Section 9.15). Then you can skip around
efficiently in any way you please.
>
> One other query, if you would be so kind as to help, is why you cannot use
> backspace to skip over a record written using list-directed formatting. I
> am using sequential access, with position set to default ('ASIS'). I am
> under the impression that a record corresponds to a line on an ASCII file,
> and when writing using list directed output, all data is written to the
one
> record.
That is not the case. Using list-directed I/O the processor is free to break
up the list into as many records as it chooses (Section 9.9). It doesn't
work with direct-access files either.
>With this understanding I see no difference between explicit
> formatting and list-directed formatting, with concerns to backspace. Is
my
> understanding a bit confused? Any help would be appreciated.
See above. In general, list-directed I/O is useful for simple applications
especially when developing or debugging programs. For more serious uses, you
really should supply your own formats or use unformatted I/O which is more
efficient and involves no potential loss of precision.
Regards,
Mike Metcalf
|