ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/07/90)
In article <1633@dinl.mmc.UUCP>, noren@dinl.uucp (Charles Noren) writes:
: C Advantages over FORTRAN:
: 1. Data Pointer Types. FORTRAN apparently still does not
: have a pointer type.
Several existing Fortrans have pointers. They're in Fortran-90.
: 4. Macros. In most C implementations, macros are expanded
: in a separate program from the actual C compiler, known as
: the C Pre-Processor (cpp). One person suggested that
: FORTRAN code could be run through cpp and thus have macros.
: I have not tried this, but it is an interesting idea.
I have done it and if you take reasonable care it works fine.
Of course, cpp is not the only macro processor around. Even for
C itself, it is often a better idea to use something like M4,
and M4 is not language-specific.
: 5. Dynamic memory allocation. f77 does not have this, but
: apparently f9x will have dynamic memory allocation.
Existing Fortrans with pointers often do have dynamic memory allocation.
Yes, it is in Fortran-90. (See the ALLOCATE statement.)
: (Question: It's been so long since I've used
: FORTRAN, but how does the EQUIVELANCE statement
: affect or not affect aliasing?)
If you're using one of the variables in an EQUIVALENCE group,
what you get when you use one of the others isn't defined.
: b. The C for statement does not have a well defined
: "control variable" and thus cannot be automatically
: vectorized.
Bogus. It is true that there is no _syntactically_ distinguished
variable, but all you have to do is watch out for a variable which
is incremented by a constant and is tested against an invariant bound.
Anything expressible as a Fortran DO statement can be expressed as a
C for () statement and can be recognised this way.
: However, it would seem that
: FORTRAN, with its way specifying a starting index (if it
: truly is part of "standard" FORTRAN and not just a vendor
: language enhancement) has the advantage here.
Yes, arbitrary lower bounds are part of the Fortran-77 standard.
: 7. C does not have the COMPLEX data type.
C++ has.
: 9. Dynamic memory. Due to the use of pointers in C,
: dynamic memory is used often in C. How and when to use
: dynamic memory (and which are the best dynamic memory
: functions) can cause debate with C programmers. With the
: use of dynamic memory come subtle bugs (memory leaks) which
: can be hard to trace.
Don't blame the bugs on "dynamic memory". Blame them on forcing
programmers to do their own storage allocation (malloc() and free()).
Don't expect Fortran in any version to be better.
--
"A 7th class of programs, correct in every way, is believed to exist by a
few computer scientists. However, no example could be found to include here."bam@bnlux0.bnl.gov (Bruce A. Martin) (06/07/90)
In article <3169@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >In article <1633@dinl.mmc.UUCP>, noren@dinl.uucp (Charles Noren) writes: > ... [Much interesting dialog.] ... [My quibble is only with the following: ] >: (Question: It's been so long since I've used >: FORTRAN, but how does the EQUIVELANCE statement >: affect or not affect aliasing?) > >If you're using one of the variables in an EQUIVALENCE group, >what you get when you use one of the others isn't defined. Welll.... Not quite! What I think you meant to say is: If you're using one of the variables in an EQUIVALENCE group, what you get when you use one of the others that has a DIFFERENT TYPE is undefined. Of course, all variables (aliases, actually) in the EQUIVALENCE group which have the SAME TYPE do become defined and have the same value after one of them has been defined (provided none of the others of differing type has become defined more recently). {Gee! It's is a lot harder to say than to understand. Anyhow, this use of EQUIVALENCE is really no different from "union".} -/s/- BAM Bruce A. Martin Grumman Aircraft Systems [Address given for identification only.] (Mailstop C02-106) [Every conceivable disclaimer applies!!] Bethpage, NY 11714-3582 [Opinions are mine only, & will change,] (516) 577-1085 [without notice, whenever appropriate!!] P.S. Sorry. I do not know what the "EQUIVELENCE" statement does! $8-D (Refer to "alt.flame.spelling" for further information.)
flint@gistdev.gist.com (Flint Pellett) (06/07/90)
I've always strongly believed that the choice of what language to use for a particular purpose depends upon the purpose you have in mind. Therefore, it is impossible for us to reasonably recommend whether your friend should switch from Fortran to C without knowing what he is trying to do. (Or whether he should forget both of them and use something else.) Here are some tidbits that may help: 1. It is rumored that AT&T will not support a FORTRAN compiler in their System V Release 4: the reason being that, with the change over from the COFF to ELF object formats they didn't feel it was worth the work to build/fix their Fortran. I don't know if this rumor is true, and even if it is I'm sure you'll be able to get 3rd party compilers. However, it is easy to get C, getting a Fortran that will compile your code correctly isn't always so easy. (I think it is rather like getting parts for a special foreign car-- you can generally do it, but it takes a lot of effort to locate them sometimes.) From my own experience, I once had to try compilers from 4 different vendors before I found one that didn't have a fatal limitation for my application. Two examples I remember: Micro-Soft's (brain-damaged) compiler only allowed values in the range from -32,767 to 32,767 in a signed INTEGER*2 (2 byte) variable: note the absence of -32,768. Because they decided to make the bitpattern 0x8000 a special case and not allow you to use it, all my code to build up 16-bit bitmaps could not be guaranteed to work unless I was willing to store all my 16 bit bitmaps into 32 bit variables. Another compiler I tried out decided that character arrays never have to be longer than 255 characters. (No, they couldn't even be nice enough to allow 256, not that it mattered- when you want to process file names with 1024 characters in the path, such a limit is death.) 2. Fortran has more developed math libraries, but the rest of the libraries available for it are far more limited. You're not likely to find standard library routines for updating /etc/passwd in any Fortran libraries: even stuff as basic as getopt() doesn't seem to have a standard in Fortran. The math stuff isn't portable either: if you like having to run scripts to change all your xor() calls into ieor() for the new machine get Fortran. 3. Optimization in C vs. Fortran has a lot less effect than other factors, such as the algorithm and how well it is written. One example: by recoding a binary search routine that was originally written in Fortran (and reasonably well) into C to call the bsearch() library routine, I made significant speed improvements in a program. When done, I had 1 line of code to maintain instead of many. I would never choose a language based on how well it can be optimized-- choose the language based upon how well it allows you to express the algorithm you're trying to write. In case you haven't guessed by now: in 95 applications out of 100 I'd recommend using C over Fortran. About the only time I ever went with Fortran was for doing solutions of complex differential equations and related numerical analysis work, because the packages to do it were available. -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 uunet!gistdev!flint or flint@gistdev.gist.com
grover@brahmand.Eng.Sun.COM (Vinod Grover) (06/08/90)
In article <3169@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >: b. The C for statement does not have a well defined >: "control variable" and thus cannot be automatically >: vectorized. > >Bogus. It is true that there is no _syntactically_ distinguished >variable, but all you have to do is watch out for a variable which >is incremented by a constant and is tested against an invariant bound. Also, make sure that the variable is not subject to hidden side-effects, if you want to vectorize the loop or perform strength reductions on operations involving that variable.
mcf@cs.mu.oz.au (Michael Flower) (06/08/90)
One thing that C really doesn't have, that Fortran has that is quite useful is variable dimensioning. Yes you can fudge it, however it is really quite nice in fortran. mcf
nick@lfcs.ed.ac.uk (Nick Rothwell) (06/08/90)
In article <915@gistdev.gist.com>, flint@gistdev (Flint Pellett) writes: >In case you haven't guessed by now: in 95 applications out of 100 >I'd recommend using C over Fortran. About the only time I ever >went with Fortran was for doing solutions of complex differential >equations and related numerical analysis work, because the packages >to do it were available. I believe I once saw mention of a third computer programming language. One which wasn't C, and wasn't FORTRAN either. Might have been my imagination. [ 1/2 :-) ] >Flint Pellett Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcsun!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ Ich weiss jetzt was kein Engel weiss
exspes@gdr.bath.ac.uk (P E Smee) (06/11/90)
In article <1633@dinl.mmc.UUCP> noren@dinl.UUCP (Charles Noren) writes: > 1. Data Structures. FORTRAN IV did not have them, modern > FORTRAN compilers do. If so, they are in as extensions, not as part of the (77) Standard. Though the *next* Standard (8X -- probably 9X by now) is expected to have them. > 2. Cleaner code structures. Apparently the newer FORTRAN > compilers have modern code structures. As one person > noted, his FORTRAN code is essentially free of statement > labels and indented for readability. The 77 Standard added a lot of these. > 3. Recursive subroutine calls. Most, if not all, modern > FORTRAN compilers can call subroutines recursively. > This is many a feature of the underlying implementation > of how arguments are passed to subroutines/functions. > (Question to langauge definition guru's: Are recursive > and reentrancy issues specified in the formal langauge > specifications of C and FORTRAN?) A manufacturer's extension, which is usually easy enough to do given the stack orientation of most O/Ses these days. The Standard says specifically that recursion and reentrancy are not permitted in a Standard-conforming program. Very specifically. (A procedure - function or subroutine - becomes 'active' when it is entered, and 'inactive' when it returns. It is invalid to for a program to enter a procedure which is already active. > 4. Free form code. Modern FORTRAN compilers allow for free > form entry of code, with similar restrictions that apply > to C code with its pre-processor statements (e.g., #define). Yes, except that spaces are still not significant and so can be put in or left out at will. I still think this is 'wrong', as making it diffcult to parse, and easy to miss errors. For example, the following: CALL SUBROUTINE (ARG, ARG, ARG) CALLSUBROUTINE(ARG,ARG,ARG) CAL LSU BRO UTI NE( ARG ,AR G,A RG) are all valid, and all say precisely the same thing. >And now a C advantage list. > >C Advantages over FORTRAN: > > 1. Data Pointer Types. FORTRAN apparently still does not > have a pointer type. Underlying argument passing > mechanisms in FORTRAN subroutines probably use pointers, > but the language definition does not have a data pointer > type. Data pointers conveniently allow referrences to > physical memory (useful for microprocessor controllers, > perhaps not useful for virtual memory machines) and the > "more natural" creation and maintenance of some data > structures such as linked lists. Will probably come to FORTRAN. > 5. Dynamic memory allocation. f77 does not have this, but > apparently f9x will have dynamic memory allocation. On the other hand, FORTRAN allows subroutines/function to have arrays whose size is not known at compile time. This makes it easy to write library stuff without needing dynamic memory (though it's not a complete substitute. In original FORTRAN, the array size needed to be passed as an argument. (Of course, someone up in the calling chain has actually got to have the storage defined.) For example, SUBROUTINE FRED (DIM1, DIM2, ARRAY) INTEGER ARRAY (DIM1, DIM2) does the right and useful thing. (This is something I wish C DID have.) >FORTRAN Advantages over C: > > 3. Fortran compilers have been around longer and are > generally better at optimization than C compilers. FORTRAN is intrinsically more optimisable than C, for reasons such as those you give later. In essence, FORTRAN contains some restrictions on use which were put in specifically to allow optimizers to hack it around. > (Question: It's been so long since I've used > FORTRAN, but how does the EQUIVELANCE statement > affect or not affect aliasing?) Two ways. First, (if you have equivalenced things of different types) it is invalid to reference the variable using any data type other than the type you used when you last stored into it. (This helps optimization, and limits aliasing.) Second, if two arguments to a function point to the same 'data chunk' (because they are EQUIVALENCED higher up) it is invalid for the function (or subroutine, keep forgetting those) to change the value of either of them. (As with ever so many of these restrictions, the compiler can't in general check. It is the programmer's responsibility to make sure they have behaved. If they haven't, the program is non-conformant, and the behaviour is undefined. > 5. *Natural* array subscripts in C must start with zero, > which for some is counter intuative (of course the C > programmer might ask what is so intuative about starting > with 1 ;-)). One person mentioned this can cause > optimization problems by defeating alias optimizations in > C, again I don't know if this is the case. Modern FORTRAN > compilers, I'm told, allow for subscripts to start at > any value (including negative integer values). That is part of the standard. Notation is B:E where B is the beginning subscript and E is the end one. For back compatibility, specifying a single subscript means 1:number. It is something else which I wish C had. It is nice to be able to define your subscript range to match whatever bit of the real world you are modelling. I know it can be simulated with C macros, but that's a fiddly bother -- just the sort of thing I pay computers to do. -- Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK P.Smee@bristol.ac.uk - ..!uunet!ukc!bsmail!p.smee - Tel +44 272 303132
nelan@enuxha.eas.asu.edu (George Nelan) (06/11/90)
In article <4574@castle.ed.ac.uk>, nick@lfcs.ed.ac.uk (Nick Rothwell) writes: | In article <915@gistdev.gist.com>, flint@gistdev (Flint Pellett) writes: | > <C vs. Fortran stuff> | | I believe I once saw mention of a third computer programming language. | | One which wasn't C, and wasn't FORTRAN either. | | Might have been my imagination. | | [ 1/2 :-) ] | So, can you provide any pointers to this alleged third computer programming language? Also, does it have higher-order functions? -- George Nelan, ERC 252, Arizona State University, Tempe, Arizona, USA, 85287 INET: nelan@enuxha.eas.asu.edu UUCP: ...{allegra,{ames,husc6,rutgers}!ncar}!noao!asuvax!nelan QOTD: Don't have a cow (it's still the twentieth century schizoid) man.
mantei@cassius.cs.uiuc.edu (Jeff Mantei) (06/12/90)
nelan@enuxha.eas.asu.edu (George Nelan) writes: >In article <4574@castle.ed.ac.uk>, nick@lfcs.ed.ac.uk (Nick Rothwell) writes: >| In article <915@gistdev.gist.com>, flint@gistdev (Flint Pellett) writes: >| > <C vs. Fortran stuff> >| >| I believe I once saw mention of a third computer programming language. >| One which wasn't C, and wasn't FORTRAN either. >| >So, can you provide any pointers to this alleged third computer programming >language? Also, does it have higher-order functions? I believe he was just talking about 'Ada'. (Relating to DoD standards.) Just a guess... Jeff Mantei mantei@cs.uiuc.edu