James Giles wrote:
>Aleksandar Donev wrote:
>
>
>>James Giles wrote:
>>
>>
>>>I think FLUSH should be in an annex instead of the body of the
>>>standard. Something like: "If your system requires it, it should
>>>look like so." It should never be necessary (or even meaningful)
>>>to explicitly flush system buffers on a modern, well designed
>>>system.
>>>
>>>
>>I disagree---there are many cases where flushing is necessary in my
>>experience. The point is that every compiler must compile codes with FLUSH,
>>so that people do not have trouble porting things. It can be empty and do
>>nothing, but it may also save you in cases like working on a cluster with
>>MPICH...
>>
>>
>
>Yes, there are many cases where flushing is necessary on old or
>poorly designed systems. But, requiring application programmers
>to know when and where those cases are is the crux of the problem.
>
>The system can *always* discover such things. Few systems even
>provide a way for applications to find out whether it needs to
>flush or not. As a result, you must flush at any point where it
>simply *might* be necessary. Why have buffers in the system at
>all?
>
>--
>J. Giles
>
>
I agree with Aleksandar.
Unfortunately, Mr. Giles misses the main point of standardization.
The point of standardizing anything is so that the user of the standard
can have predictable behavior of the thing that is standardized. This
results in tremendous reduction of wasted time and effort. In fact,
complex technological products are impossible without standards that are
widely recognized and used.
The very fact that you can read this message is the result of
hundreds or even thousands of standards being followed, right down to
the electricity that runs your computer. If you don't think that's
important, well, just travel between the USA and Europe. There are
different standards in place for the shape of the plug and the voltage
that runs on the lines. You need an adapter to be able to plug your
American PC into a European outlet or vice versa.
Now, it is impossible for programming language standards to provide
100% portability. This is due to differences in:
* Compiler design philosophy
* Hardware
* Operating systems (besides the various Unixes, there also are Fortran
compilers for Windows and VMS)
However, programming language standards don't need 100% coverage in
order to be highly effective. 99%, 98%, or even 95% coverage is highly
useful. Obviously, the higher the level of coverage, the fewer and less
costly the portability problems. Hence, it makes sense to standardize
the FLUSH statement.
There also is an imbalance between the cost of an unnecessary flush
operation and not flushing when necessary. If you flush at a time it is
not needed, the compiler (or I/O library) simply does a no-op. However,
if the system does not flush when necessary, there is a serious risk of
the loss of valuable information. I know. The second consequence has
happened to me. Thus, I want the FLUSH statement and I want it
standardized so I can depend on it no matter what system I work on.
That is why I strongly supported it in J3 meetings.
--
Sincerely,
Craig T. Dedo
17130 W. Burleigh Place E-mail: [log in to unmask]
Brookfield, WI 53005-2759 Voice Phone: (262) 783-5869
USA Fax Phone: (262) 783-5928
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- Benjamin Franklin
(1759)
|