Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!cmcl2!lanl!jlg From: jlg@lanl.gov (Jim Giles) Newsgroups: comp.lang.fortran Subject: Re: My widget is more portable than yours (was Fortan versus C) Message-ID: <4089@lanl.gov> Date: 23 Sep 88 20:25:12 GMT References: <1040@amelia.nas.nasa.gov> Organization: Los Alamos National Laboratory Lines: 47 From article <1040@amelia.nas.nasa.gov>, by fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts): > [... example of non-porting C ...] > This is an argument by anecdote. [...] Yes, it's argument by anecdote. That is, it's exactly the sort of argument that's always used by C enthusiasts against Fortran. If it's invalid for me to use such arguments, then it's also invalid for C supporters. > It seems they were doing something like > COMMON /BLOCK1/ A(10000), I(1000) > COMMON /BLOCK2/ B(10000) > DO 10 I = 1, 30000 > A(I) = 0.0 > 10 CONTINUE > They were very upset when CDC wouldn't "fix" the problem.) This argument is invalid because the above is non-standard (not only that, the use of I in the do loop is illegal since I is declared to be an array). Any non-standard Fortran shouldn't be expected to port without _some_ degree of rewriting. The point about C is that THERE IS NO STANDARD. So, any example of non-portable C code I show you will demonstrate _my_ point in a perfectly valid manner. When a C standard becomes available, _then_ you can point to some mistake in my C examples - not until. One problem still remains with C, however. The proposed standard still contains some deliberately ambiguous forms. So, even after the standard exists, there will be non-portable standard conforming code. The Fortran committee seeks to avoid ambiguity - as a result, standard conforming Fortran code usually _does_ port. If it doesn't, it's _usually_ a compiler or library bug. Only very rarely does an ambiguous Fortran construct turn up - and when it does, there is usually a tacit agreement among users and implementors - an ambiguous feature is, for all practical purposes, a non-standard one. When THERE IS a C standard, C will be more portable. When the C standard starts to outlaw ambiguous features, C will be even as portable as Fortran (maybe). In the meantime, the Fortran standards committee is busy adding (I hope) most of the features that C users complain are missing. Fortran 77 will remain more portable that C throughout this change. Fortran 8x will also be portable, but only to those places which support the new standard. This latter problem faces C users as well - the new C standard will not be universally available right from the start. J. Giles Los Alamos