Re: Conversion from int to char

Gary Scott wrote:

Ron Ford wrote:

On Fri, 29 Aug 2008 21:43:33 -0700, Richard Maine posted:


Richard Maine <nospam@xxxxxxxxxxxxx> wrote:


Gary Scott <garylscott@xxxxxxxxxxxxx> wrote:


Ron Ford wrote:


What I don't see is a file. By "file," do people mean "whatever internal
variables you used to read the data?"


It's an abstract concept...the character variable is a substitute for a
"file".


And that's really, really how you want to think of it. Because if you
think of it that way, most other things about its usage pretty much
follow (ok, not all of them, but most of the basics). For a very
particular example, it is "obvious" when you want to do an internal read
versus an internal write. If that isn't obvious, then I'd say you aren't
yet really thinking about the character variable as a substitute for a
file. If you don't think of it that way, then you'll be like all the
other people who just try to memorize when to use read versus write, and
who guess wrong pretty much 50% of the time.


I know, following up to myself, but I realize I didn't adequately finish
explaining the thought in answer to Paul.



This is what MR&C has to illustrate this point:

integer::ival(30), key, i
character(30)::buffer
character(6) :: form(3) (/ '(30i1)', '(15i2)', '(10i3)' /)
read (*, '(a30,i1)') buffer, key
read (buffer, form (key)) (ival(i), i=1,30/key)

I don't quite follow execution here. Maybe someone could comment on the
ideas from this thread with this source as reference.

Thus just changing the terminology is not going to help anyone much in
that while they might then be able to find the syntax, they won't be
able to remember how to use it without looking it up every time. Much
better, in my opinion, is to put index entries or whatever for the terms
you think people are more likely to look up and say "see internal I/O".
Yep, you need that kind of cross-referencing to help them find it. But
once they do find it, you want them to think of it as internal I/O
instead of as something like "smagic syntax for converting between
character and numeric".



There's a lot of different io in fortran. I was never particularly good
with io in any syntax. What's more, there's so many options that it's hard
to keep the relevant portion in view. The open statement has a dozen
possible attributes anyways, which isn't bad. It simply takes longer for
the whole gamut to sink in.


My goodness, if you think the open statement is bad, just try deciphering any Win32 API. Talk about a nightmare of confusion.

....and at least Fortran has optional arguments with default values for most things...win32 you gotta fill in every low-level detail to the last nit.

--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows it can't be done.

-- Henry Ford
.

Relevant Pages

  • Re: a cute program
    ... As in my reply to bru, see any Fortran text for the syntax of the PRINT ... Usenet is not a substitute for a Fortran text. ...
    (comp.lang.fortran)
  • Re: File reading problem
    ... Gary Scott wrote: ... Meanwhile, I completely have forgotten Fortran, worked for several ... I'm not quite sure the format matches the write statement, depends on the dimension of YS and the value of NTIME. ... Support the Original G95 Project: http://www.g95.org ...
    (comp.lang.fortran)
  • Re: Conversion from int to char
    ... It's an abstract concept...the character variable is a substitute for a ... I don't quite follow execution here. ... that while they might then be able to find the syntax, ... you want them to think of it as internal I/O ...
    (comp.lang.fortran)
  • Re: Is there a way like this in Fortran?
    ... Gary Scott wrote: ... I don't want to defend C, as I find it a rather horrible language overall, but I think this would be a convenience feature in Fortran. ... Since these would not be expression-level operators merely assignment operators, the arguments over there being too many precedence levels would not apply. ... Correction, I oppose redundancy regardless of compromise of clarity, but especially so. ...
    (comp.lang.fortran)
  • Re: Threads [was Re: Final Procedure]
    ... Gary Scott wrote: ... Fortran Library: http://www.fortranlib.com ... Support the Original G95 Project: http://www.g95.org ... Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html ...
    (comp.lang.fortran)