Somewhat belated rely as I have been on vacation for 3 weeks. I see
that others have addressed most of the comments I would have made. I
have just a few additional side comments.
On Jul 6, 2005, at 1:23 PM, Clive Page wrote:
> I had not appreciated the substantial differences between formatted
> and unformatted stream I/O, and had only looked properly at the
> sections of the Standard describing the former.
Ouch! Then no wonder you were confused. They are indeed very different.
Furthermore, unformatted is *FAR* simpler. If you had to concentrate
only on one of them I'd sure recommend looking at unformatted instead
of formatted.
In fact, my original proposal for stream I/O didn't include formatted
because I was trying to keep things simple. Formatted streams are
substantially more complicated and yet don't add anything that I regard
as critically new, so I figured that omitting them would help the
cost/benefit tradeoff. But the gist of the responses to my proposal was
that "everyone" liked the idea, but many people also wanted formatted
capability, so it got added. Almost all of the subsequent work on the
subject was on formatted... because it had all the complications that
needed work. At times I wish I had resisted the request to add
formatted....
In regards to the differences:
A formatted stream file is really the same thing as a sequential text
file. It is perhaps a bit of a misnomer to refer to it as a kind of
file at all (but the standard does and that's probably my fault at
least in part). It is a different way to access the same kind of file.
The form of access is more convenient in some situations, but I don't
personally regard formatted streams as a critical new feature.
In particular, a formatted stream file *IS* also a record file. It
comes complete with all the properties that record files have - whether
you choose to call these "shackles" on not. I personally happen to
think of record files as a case of the operating system providing
important additional support that would otherwise have to be done by
the user. I don't view the fact that most current operating systems
omit record management support to be an improvement. But I digress... I
think that many of the restrictions and oddities of formatted stream
access can be best understood through recognizing that this really is a
record file.
In that regard, I have not time to do a detailed review of the web page
you wrote up, but I found one point in it to be seriously misleading.
No, formatted stream files (aka formatted sequential files) do *NOT*
have the structure of a line of text followed by a delimiter. If you
try to think of that as their basic definition, then you will probably
get confused by many things. Their structure is just a line of text in
a record. The record is defined by the processor (compiler). In that
regard, they are just as system-dependent as unformatted files. It just
happens that essentially all systems define and support a suitable text
file structure, which Fortran implementations naturally use. (The
Fortran standard doesn't require that Fortran sequential formatted
files be compatible with such things as text editors or anything else
on the system, but the market does require it).
With formatted stream access, the newline character is used in the
output data to *REPRESENT* the end of a record. This does not in any
way imply that records are actually stored in such a manner. If I
recall correctly, the same is true of C. The possible translations
between this representation and the actual file structure relate to
some of the restrictions.
Unformatted streams provide capability that is fundamentally new and
was really *VERY* painful to do portably and within the context of
previous Fortran standards. Trust me on that :-(. They are also pretty
simple.
> The whole point of stream I/O, I thought, was that for the first time
> it frees the Fortran programmer from the shackles of record-based I/O.
I would also say that this majorly mischaracterized the main
motivations for adding stream I/O. Well, I guess you've got in in other
material, but with a different emphasis than I would use. I consider
the primary motivation for unformatted stream access to be
interoperability (and formatted stream was just an "add-on" in my view,
as I mention above). In fact, stream I/O originally was introduced as
part of the C interop stuff, though it has subsequently been identified
as a separate feature in its own right. You need unformatted stream to
deal with independently defined file formats (such as graphics image
files and many others). Prior to stream I/O, there was no way to do
this that was sanctioned by the standard.
"Faking it" with direct access files often worked, but that involved
making assumptions about implementation details that were not
guaranteed by the standard (and the assumptions were not always
correct). It was also quite a bit of work and had multiple
complications. It was one area where I regularly recommended that
people go ahead and use vendor extensions.
The lack of record structure is more of a side matter to me. That's a
consequence of the interop needs rather than a basic requirement on its
own.
As with formatted streams, there are times when unformatted streams are
more convenient, even independent of interop issues. This is
particularly so when you need random access, but don't want to be
shackled with a fixed record size (the limitation to fixed record size
*IS* something I regard as a shackle, though one I understand the
reasons for). Even if you do need a record structure, if you need both
random access and variable record size, it is usually far easier to do
your own record management starting from unformatted stream files than
to hack up something from what was available in previous Fortran
standards.
But if variable-size random access records were the main goal, I think
that could have been more directly addressed. I view the interop issue
as the primary goal, with the other benefits as handy "free" extras.
Admittedly, the separation here isn't 100%; sometimes interoperable
files have requirements for random access to variable-sized chunks of
data, so it is not a coincidence that you end up with ways to do that.
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
