open(unit=3, file='myData.txt')
m=1
do while (.true.)
read(3,end=10,fmt=*)x(m),y1(m)
m=m+1
enddo
10 close(unit=3)
Thanks
Michael
integer:: ios
...
open(unit=3, file='myData.txt')
m = 1
do
read(3,fmt=*,iostat=ios) x(m),y1(m)
if (ios < 0) exit
m = m + 1
end do
close(unit=3)
Thanks much
I appreciate the quick response
Michael
> integer:: ios
> ...
> open(unit=3, file='myData.txt')
> m = 1
> do
> read(3,fmt=*,iostat=ios) x(m),y1(m)
> if (ios < 0) exit
> m = m + 1
> end do
> close(unit=3)
While that is a pretty literal translation of teh surface of the
original code, I'd advise against doing it quite that way. I would
advocate at least changing the test to ios/=0 instead of ios<0.
With the ios<0 test, the code continues trying to read after
encountering an error. Reading after an error would violate the
standard. Worse, however, it has a good chance of becomming an infinite
loop, always reporting an error and never an eof.
Better might be to output an error message and stop if ios>0. That
probably more accurately mimics what the original code would do in that
case.
While I'm on the subject of making suggestions for this code, I'd
suggest a dimension limit check on any I/O loop like this. That applies
to the original code as well as the modified version.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
As far as I know, this won't handle the case where the read encounters
an error instead of an end-of-file. You'd have to test for ios > 0 and
recover from the error or terminate the program.
I don't know if iostat values are portable. If that's an issue, and
input errors are to be treated as catastrophic, then the 'end=<label>'
specifier might be the easiest (if not the most elegant) way of doing this.
(I assume the code checks for 'm' being out of bounds for 'x' or 'y1'.)
Louis
> I don't know if iostat values are portable.
The distinction between 0, <0, and >0 is standard and portable.
Otherwise, specific values are not portable (although f2003 adds
portable way to tell what the eof and eor values are).
[...]
> While I'm on the subject of making suggestions for this code, I'd
> suggest a dimension limit check on any I/O loop like this. That applies
> to the original code as well as the modified version.
>
As the OP is not using a dynamically allocated array, the
check for the dimension limit is very easy to do:
open(unit=3, file='myData.txt')
do m = 1,size(x)
read(3,fmt=*,iostat=ios) x(m),y1(m)
if (ios < 0) exit
if (ios > 0) then
write(*,*) 'Error reading data pair ',m
stop
endif
end do
close(unit=3)
Regards,
Arjen
> As the OP is not using a dynamically allocated array, the
> check for the dimension limit is very easy to do:
...
> do m = 1,size(x)
> read(3,fmt=*,iostat=ios) x(m),y1(m)
> if (ios < 0) exit
> if (ios > 0) then
> write(*,*) 'Error reading data pair ',m
> stop
> endif
> end do
Nothing unique to dynamically sized arrays there. It does assume that
the array size is set before this loop, as opposed to being adjusted to
accomdate the data being read; I suppose that's probably what you were
saying.
This simple method does avoid indexing the array out of bounds. However,
it does so by just ignoring any further data. That might be acceptable,
depending on the application. If you want to generate an error message
for that condition, it takes a little more work. In particular, you tend
to need to read into a temporary variable instead of directly into the
arrays because you need to try one read past the end of the array in
order to get the boundary condition right.
Hm, yes, that is true - with "dynamically allocated arrays", I was
thinking
of arrays that get expanded during the loop to allow the new data to
be
stored.
Detecting extra data could be done by using a bound like "size(x)+1"
and
storing the data only if the loop index is lower than that. The main
advantage above the do loop without any condition is that you can not
go wrong with initialising or incrementing the index.
Regards,
Arjen