Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rutgers!njin!uupsi!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.c
Subject: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <14200@lambda.UUCP>
Date: 23 Jan 90 00:55:12 GMT
References: <12974@cbnewsc.ATT.COM>
Distribution: na
Lines: 59

From article <12974@cbnewsc.ATT.COM>, by levy@cbnewsc.ATT.COM (Daniel R. Levy):
> [... Use of Character variables in Fortran ...]
>
> Well... depends on what you're doing with the strings.  Fortran uses the
> convention that character strings are right-padded with blanks (for things
                            ^^^^^^^

Depends on how you define strings.  I don't define Fortran character
variables as being strings.  They are fixed length.  I define them
to be a type of character array with some useful operators defined for
them.

A genuine string type in Fortran would certainly be a welcome addition.
But, the lack of such a type doesn't make C the language of choice for
the manipulation of character data.

> C
> C  FORTRAN77 code to read two lines (assumed 80-characters wide, max),
> C  put their concatention in a buffer,
> C  then print the concatenation between double quotes
> [... This is followed by a program which doesn't do the above
>      described operation.   ...]
>
> Ugh.  Now let's try that in C...
> [...  This is followed by a C program which doesn't do either the
>       operation described for the Fortran NOR the operation that
>       the Fortran version _actually_does_.    ...]
> 
> 'Nuff said.

Yes - "'Nuff said"!  You clearly don't have any idea what you're talking
about.  A Fortran program which does what the above comment lines claims
would have been as short as your C version (and whould have been more
efficient because the C version included a few locations where "pre-
scanning' the strings would have been required.

Instead of doing what the comments claim, your Fortran code laboriously
stripped the blanks from the input strings (a fact which accounts for
MOST of the bulk of the program).  Yet, the C code wasn't subject to
that laborious process (in spite of the possible presence of trailing
blanks).

To be sure, to get the Fortran version to match the behaviour of the
C version (of vice versa) would have required some additional coding.
And, for those _few_ simple things like your example, the C code is
slightly shorter (at the expense of speed).  Fortran is not perfect
either: most applications require the user to carry around string
lengths in order to do much of the work required.  In order to
provide efficiency, the C programmer ALSO would have to maintain
string lengths explicitly.  In this case, Fortran's improved
syntax is a direct win.

A "perfect" language would provide a genuine string type which
maintained the string lengths implicitly (and NOT by terminating
with some special character).  The "perfect" language would also
have substring and concatenation built into the syntax instead of
function calls like C has.

J. Giles