Xref: utzoo comp.lang.fortran:804 comp.lang.c:10901
Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!husc6!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.lang.fortran,comp.lang.c
Subject: Re: Should I convert FORTRAN code to C?
Keywords: language conversions, FORTRAN, c
Message-ID: <1189@mcgill-vision.UUCP>
Date: 26 Jun 88 09:55:45 GMT
References: <2742@utastro.UUCP> <20008@beta.UUCP> <224@raunvis.UUCP> <20340@beta.lanl.gov>
Organization: McGill University, Montreal
Lines: 31

In article <20340@beta.lanl.gov>, jlg@beta.lanl.gov (Jim Giles) writes:
> In article <224@raunvis.UUCP>, kjartan@raunvis.UUCP (Kjartan Pierre Emilsson Jardedlisfraedi) writes:
>> [...]
> The Problem is that 2-d arrays are not optimizable because they are
> immediately turned into pointer-to-pointer-to-data type of
> constructs.

Real 2-d arrays turn into pointer-to-array, not pointer-to-pointer.  If
you have one of these dynamically-allocated arrays that have been
bandied about, which is really an array of pointers to blocks of data,
*that* is pointer-to-pointer.

>> ii) You can define your own data structures,
> This capability is NOT an adequate replacement for the complex data
> type.  Complex is more than just a pair of reals, [...]

It's both more and less powerful.  To put it another way, FORTRAN's
COMPLEX data type is NOT an adequate replacement for the ability to
define custom data types.

> No use of C programming constructs can do this:  [FORTRAN example]
> C provides no way to even do this calculation without function calls.

Sure it does, it just takes a little more code than the FORTRAN
example.  But that's a strawman anyway.  For every such example, I can
write one in C that FORTRAN similarly "can't" do.

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu