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