replica nfl jerseysreplica nfl jerseyssoccer jerseyreplica nfl jerseys forums.silverfrost.com :: View topic - Is this default behavior for READ(100,*) charVar
forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Is this default behavior for READ(100,*) charVar

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2937
Location: South Pole, Antarctica
PostPosted: Sat May 10, 2014 11:52 pm    Post subject: Is this default behavior for READ(100,*) charVar Reply with quote
If character variable defined for example like this

character charVar*256

and then you read the line of text in the file like this

READ(100,*) charVar

then only few initial bytes are read. Is this default behavior in Fortran? If this is the case then it's extremely antiintuitive.

The FTN95 reads the whole line in file only if you explicitly define the format

READ(100,'(A)') charVar
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK
PostPosted: Sun May 11, 2014 9:38 am    Post subject: Reply with quote
What is the string you are trying to read?

List directed I/O of string data has a number of restrictions:

The string must not start with a digit sequence then *.
It cannot contain separators (commas or slashes (/))
It cannot contain whitespace (spaces or tabs).
A newline terminates the string unless escaped with a backslash (\).
It must not begin with a quote (single or double).

Any string not meeting the above restrictions must be enclosed (front and back) in single or double quotes.

For practical purposes, you are better using format (A) unless you know the string will obey the rules.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2937
Location: South Pole, Antarctica
PostPosted: Mon May 12, 2014 12:04 am    Post subject: Reply with quote
Thanks, that explains its behavior, now i see that it has really a lot of restrictions with some general logic which came from applying it to other types of variables

I was reading regular data file with a lot of numbers in the line and expected that * format in the case of character variable was supposed to allow to read everything till the end of the line or till the character variable length
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2621
Location: Sydney
PostPosted: Mon May 12, 2014 2:21 am    Post subject: Reply with quote
Dan,

I have also found that "read (lu,*) string" does not work very well and prefer fmt='(a)'
Have you looked at list directed input, although I doubt it would be better than fmt=(a).

I tried the following simple code example with the following text input and the results are fairly predictable, with <space> or , being a field seperator for read (,*).
Code:
      character line*80
!
      do
         read (*,*) line
         write (*,*) trim (line)
      end do
      end

aaa
this is a lot
"this is a lot"
123,33
'this is more'


I have a general numeric field reading routine which
* first reads a line of text into a character string,
* parse the character string by replacing <space>, <tab> or ';' with a ',' and then
* reads using a format statement, such as fmt=(i15,3f15.0), using the ',' as a recognised field seperator. (15 is big and expect ',' to terminate each number)
* for repeated spaces, I only replace the first space

I do this as I do get text input files which use any of <space>, <tab> or ; as well as , for the number field seperator as some of these characters are not recognised by the Fortran Standard. (something worth noting, before you complain too loudly about what read (,*) does or doesn't do!)
Note, if <tab> (<ht>) is expected in the file, then you have to call READ_TABS@(unitno) immediately after the OPEN statement to retain the tab character in the character input field, otherwise they are replaced by any number of spaces.
Further care is required if non standard text fields are expected. (Standard text fields expect to be enclosed as "string" or 'string'.)
All this can be placed in a subroutine get_line_string to make it more robust.

John
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2937
Location: South Pole, Antarctica
PostPosted: Mon May 12, 2014 8:15 am    Post subject: Reply with quote
John, Yes, this program works like my code gave me and how David indicated. Thanks for idea of transformation of the line into more standard readable for compiler format. I was always parsing the line after reading it with fmt=(a) by much more cumbersome way catching all spaces and looking for all beginnings and ends of each numbers in the line. As a results of that i suspect reading and parsing of some GB size files take many annoying minutes
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group