How to convert integer to character (string) ?
Marco A. Garcia
character(len=20)::MyStr
integer::i
i=10
write(MyStr,'(i5.5)') i
stop
end
change the format and the length of the string to whatever you need.
--
Marco A. Garcia
Canaima Software
1632 Dale Street
San Diego, CA 92102
Tel/Fax: (619) 233-6831
http://www.canaimasoft.com
Developers of f90SQL the database connectivity library for Fortran, and
f90VB the library for seamless Fortran-VB integration
Kunho Kim <kun...@engin.umich.edu> wrote in message
news:37EEC6DD...@engin.umich.edu...
> Hi, I am wondering
>
> "how to convert integer to character string ?"
>
> In C++, there is a function '_itoa()' which does the same thing.
> But, I can't find how to do in Fortran.
>
> If you happen to know how to do, please teach me !
>
> <a href="mailto:kun...@engin.umich.edu">kun...@engin.umich.edu</a>
>
> Thank you !
>
> --
> Kunho Kim kun...@engin.umich.edu
> http://www-personal.umich.edu/~kunhok
> 2200 Fuller Court, Apt. # 108B
> Ann Arbor, MI 48105 (TEL) (734) 214-1421
>
Keith Moodie
>
> Hi, I am wondering
>
> "how to convert integer to character string ?"
>
> In C++, there is a function '_itoa()' which does the same thing.
> But, I can't find how to do in Fortran.
>
> If you happen to know how to do, please teach me !
You do it using internal writes or reads.
This example converts a string to integers.
integer year, month, day
character*10 date_str
date_str = "1999-08-25"
READ ( date_str( 1:4 ), '(I4)'), year ! 1999-08-25
READ ( date_str( 6:7 ), '(I2)'), month ! 123456789
READ ( date_str( 9:10), '(I2)'), day
I think that to convert an integer to a string is like this
WRITE ( date_str( 1:4 ), '(I4)'), year
which will set the first 4 characters of date_str from the integer year
or
READ ( year, * ), date_str
You can also use this method for swapping bytes and lots of other
things.
>
> <a href="mailto:kun...@engin.umich.edu">kun...@engin.umich.edu</a>
>
> Thank you !
>
> --
> Kunho Kim kun...@engin.umich.edu
> http://www-personal.umich.edu/~kunhok
> 2200 Fuller Court, Apt. # 108B
> Ann Arbor, MI 48105 (TEL) (734) 214-1421
--
Keith Moodie
moo...@dnr.qld.gov.au
Jim McMahon
>Hi, I am wondering
>"how to convert integer to character string ?"
>In C++, there is a function '_itoa()' which does the same thing.
>But, I can't find how to do in Fortran.
>If you happen to know how to do, please teach me !
><a href="mailto:kun...@engin.umich.edu">kun...@engin.umich.edu</a>
>Thank you !
>--
>Kunho Kim kun...@engin.umich.edu
>http://www-personal.umich.edu/~kunhok
>2200 Fuller Court, Apt. # 108B
>Ann Arbor, MI 48105 (TEL) (734) 214-1421
Some versions of Fortran have ENCODE & DECODE statements that can
accomplish this. These statements were extensions to Fortan-77, I
don't know if they or some equivalent have been incorporated into the
F90 or F95 standards. As others have suggested, you can also try out
what are called "internal" read & write statements.
Being ordinary and nothing special is a full-time job.
mcma...@flash.net (Jim McMahon in real life)
Richard Maine
> Some versions of Fortran have ENCODE & DECODE statements that can
> accomplish this. These statements were extensions to Fortan-77, I
> don't know if they or some equivalent have been incorporated into the
> F90 or F95 standards. As others have suggested, you can also try out
> what are called "internal" read & write statements.
The internal read/write are the "some equivalent" that was
incorporated into the standard. A lot of current compilers don't
support ENCODE/DECODE, and I forsee them becoming less supported over
time. They have *NO* advantages that I can think of over internal
read/write.
I strongly recommend that nobody even think about using ENCODE/DECODE
for new code (and the original poster was clearly asking how to do
something in new code rather than how to interpret old code). The
only reasons one should even need to know about ENCODE/DECODE are for
1. Historical purposes of understanding the language development.
or
2. Understanding and/or fixing old code that uses them. This happens
with fair regularity on this newsgroup when someone discovers that
old code using ENCODE/DECODE won't compile on some compiler, so they
need to figure out how to fix it.
--
Richard Maine
ma...@qnet.com
Jim McMahon
>mcma...@flash.net (Jim McMahon) writes:
>> Kunho Kim <kun...@engin.umich.edu> wrote:
>> >"how to convert integer to character string ?"
>> Some versions of Fortran have ENCODE & DECODE statements that can
>> accomplish this. These statements were extensions to Fortan-77, I
>> don't know if they or some equivalent have been incorporated into the
>> F90 or F95 standards. As others have suggested, you can also try out
>> what are called "internal" read & write statements.
>The internal read/write are the "some equivalent" that was
>incorporated into the standard. A lot of current compilers don't
>support ENCODE/DECODE, and I forsee them becoming less supported over
>time. They have *NO* advantages that I can think of over internal
>read/write.
The main advantage I can think of is ease of use. I simply have found
that for myself, the ENDCODE and DECODE statements were easier to use
than internal writes. Of course, I've never used F90 or F95, so maybe
things have gotten easier.
>I strongly recommend that nobody even think about using ENCODE/DECODE
>for new code (and the original poster was clearly asking how to do
>something in new code rather than how to interpret old code). The
>only reasons one should even need to know about ENCODE/DECODE are for
I concur that in developing new code one should adhere to current
standards and stay away from using language extensions, especially if
portability is an issue.
>1. Historical purposes of understanding the language development.
>or
>2. Understanding and/or fixing old code that uses them. This happens
> with fair regularity on this newsgroup when someone discovers that
> old code using ENCODE/DECODE won't compile on some compiler, so they
> need to figure out how to fix it.
>--
>Richard Maine
>ma...@qnet.com
Thanks for the info on the standard, since I don't use Fortran
regularly anymore and the two Fortran compilers I do use are both F77
based (one is *almost* F90) with lots of proprietary extensions. Keep
hoping one day I'll get a job requiring F95, because I'd like to play
with it.
Richard Maine
> Richard Maine <ma...@qnet.com> wrote:
> >A lot of current compilers don't
> >support ENCODE/DECODE, and I forsee them becoming less supported over
> >time. They have *NO* advantages that I can think of over internal
> >read/write.
>
> The main advantage I can think of is ease of use. I simply have found
> that for myself, the ENDCODE and DECODE statements were easier to use
> than internal writes. Of course, I've never used F90 or F95, so maybe
> things have gotten easier.
Just shows, I guess, that "ease of use" judgements vary. I always
found encode and decode moderately cryptic. For example, you need
that extra "argument" to tell it how many characters to read/write.
On the other hand, once I started thinking about internal read/write
as just reading/writing from/to the string instead of a file, then
it all seemed natural. I won't try to argue the point;
different stroke....
One distinction that I forgot to mention before is pretty important.
Being from the era before character variables, ENCODE/DECODE do *NOT*
work with actual character variables. Well, I suppose some vendors
might have made such an extension to the defacto standard. Encode/decode
were never formally standardized, but there was a pretty common
defacto standardization of them, even though it wasn't universal;
character variables were not part of that defacto standard. With
encode/decode, the character data is stored in Hollerith form in
numeric variables.
In contrast internal read/write works *ONLY* with character variables.
for the "file"; it won't do Hollerith-like things if you give it a
numeric "file" variable. One can certainly use various tricks,
but they definitely count as tricks, and I could see that as confusing.
So if you actually *WANT* Hollerith-like stuff instead of real character
variables, then, yes, I can see that internal i/o is tricky (though
its still more portable...not that portability of Hollerith was ever
great without a lot of care).
F90/f95 Haven't changed majorly in regard to internal I/O. The one
thing that I can think of that notably improved internal writes was
that f90 allows list-directed formatting with internal writes, whereas
f77 didn't.
--
Richard Maine
ma...@altair.dfrc.nasa.gov
Jim McMahon
>mcma...@flash.net (Jim McMahon) writes:
>> Richard Maine <ma...@qnet.com> wrote:
>--
>Richard Maine
>ma...@altair.dfrc.nasa.gov
Thanks for the good and interesting backrgound information. The
Fortran I grew up on, in my first programming job (1985), was VAX
Fortran with lots of extensions to F77. Character variables were part
of the standard at that time, and the VAX ENCODE/DECODE worked on
them, but I wasn't aware of the history of ENCODE/DECODE - the only
reason I knew it wasn't standard was that it was in blue text as
opposed to black in the manuals.
DEC had LOTS of blue pages - being a young enthusiastic programmer, I
used every thing I could possibly find in blue, because it was all the
"cool" stuff, like records, common data dictionaries, extended I/O
options, screen/display management, and the like. I got lucky,
because the code I wrote never had to be ported anywhere - I still
have some of it, but I have nowhere to run it :(
Your points about portability are well taken.