Re: The concept of a record

LC's No-Spam Newsreading account <nospam@xxxxxxxxxxxxxx> wrote:

SEQUENTIAL FORMATTED...
DIRECT UNFORMATTED...

DIRECT FORMATTED is possible if you want to output readable text
files, but be able to access records at random. But one could also
read unformatted into a string, and use internal i/o

Direct access formatted is *NOT* typically a readable text file. It is
likely to not have line terminators. Adding them manually is posssible,
but non-portable. Implementations can vary on this.

I personally have (almost?) never used direct access formatted, but I've
heard from people who do.


SEQUENTIAL UNFORMATTED according to me should be avoided, because
the way the variable record length is coded may be OS and language
dependent, and therefore not portable or interoperable ... it means
looking for troubles ! I believe I used it only in very few special
cases when writing over named pipes.

Sequential unformatted is extremely widespread and has lots of good
reasons for use. It was one of the only 2 options available until f77
(as there was formerly no direct access). You are right that it can have
portability issues. But that is not always critical. And there are times
when it is important, but not so much so as to completely overwhelm all
other considerations. The fixed record lengths of direct access can
sometimes be a significant barrier. Formatted I/O has a huge performance
penalty, in addition to the potential problems of loss of precision.

Note also that the portability of direct access unformatted is also not
guaranteed. In fact the standard says nothing that requires portability
of such files any more than it does of sequential formatted. The most
common implementation choice of direct access unformatted happens to be
more portable than the most common implementation choices of sequential
unformatted, but this is not specified by the standfard. There are
implementations that don't use the most common choice for direct
acccess. Plus, of course, you won't have portability in any case across
machines with different data representations.

For f2003, the portability and interoperability of unformatted stream is
probably the best you will be able to get for unformatted. That is the
only case of unformatted I/O where the standard actually does address
the issue.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: What can be done in FORTRAN that cannot be done in C/C++?
    ... and reads a single character at a time. ... has several portability problems in practice, ... open a direct access file with a record length of one character, ... of 1 was special-cased to mean something like stream I/O. ...
    (comp.lang.fortran)
  • Re: Read the fortran unformatted binary data.
    ... UNFORMMATED I/O is not necesarily record oriented. ... Both sequential and direct access imply a record file. ... The alternative to record I/O is referred to in the Fortran standard as ...
    (comp.lang.fortran)
  • Re: Namelist I/O and direct access files
    ... > to remember the last time I used Fortran direct access I/O, ... direct access tend to write data with non compiler-dependent ... deal with non-Fortran formats that don't have Fortran record ... stream I/O will generally be a better way to do this. ...
    (comp.lang.fortran)
  • Re: Namelist I/O and direct access files
    ... I'm not quite sure what direct access has to do with saving disk ... The io length inquire is only relevant for unformatted I/O. ... to specify the rec=1. ...
    (comp.lang.fortran)
  • Re: Replace one single line in a ascii data file
    ... Will formatted stream I/O let me change things? ... sequential file everything after that point is lost. ... One reason for this is that is the way tape I/O works ... The first direct access I/O system I knew and used was on ...
    (comp.lang.fortran)