Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site ukma.UUCP Path: utzoo!watmath!clyde!cbosgd!hasmed!qusavx!ukma!david From: david@ukma.UUCP (David Herron, NPR Lover) Newsgroups: net.lang.c,net.lang.f77 Subject: Re: Converting FORTRAN to C Message-ID: <435@ukma.UUCP> Date: Wed, 26-Dec-84 21:58:43 EST Article-I.D.: ukma.435 Posted: Wed Dec 26 21:58:43 1984 Date-Received: Fri, 28-Dec-84 06:01:52 EST Organization: Univ. of KY Mathematical Sciences Lines: 106 [ I don't write until I supply stuff I am talking about ... ] > From: dgary@ecsvax.UUCP (D Gary Grady) > Newsgroups: net.lang.c,net.lang.f77 > Subject: Re: Converting FORTRAN to C > Message-ID: <396@ecsvax.UUCP> > Date: Wed, 19-Dec-84 10:13:26 EST > <> > There is a real problem in converting FORTRAN to C, because there is one > FORTRAN feature that is widely used and not duplicated in C: the > ability to pass varying-sized arrays as parameters. That is, the > following is not legal C, but the equivalent is legal FORTRAN: Does C not allow this? Gee, what about that BASIC interpretor I wrote a year ago that used arrays of int (varying size) to store the intermediate code? These arrays got passed to most of the routines in the interpretor. My code worked too. > C: FORTRAN: > subr(array, size) SUBROUTINE SUBR(ARRAY,ISIZE) > int size; INTEGER ISIZE > float array[size][]; REAL ARRAY(1,ISIZE) > { ... ... > } RETURN > END > (I don't believe C formally specifies the order of array elements, but > in practice the row-major form is used, I think. FORTRAN, of course, > stores column-major.) There ARE a number of implied pushes to this storage format. I just checked the proposed standard on this. No specific mention (that I could find) was made, BUT.... There was a discussion on initializers. A pertinent example from the text is: float y[4][3] = { { 1, 3, 5 }, { 2, 4, 6 }, { 3, 5, 7 }, }; is a definition with a completely bracketed initialization: 1, 3, and 5 initialize the first row of the array object y[0], namely y[0][0], y[0][1], and y[0][2]. Likewise the next two lines initialize y[1] and y[2]. The initializer ends earli, so y[3] is initialized with 0's. [page 41, edition as of October 17, 1984] Which certainly isn't proof, but at least implication of proof. Proof is of the form of a long winded preaching on C. You will remember that an array is nothing more than "const int *x", where x points at a block of memory that is the array. The notation of "int x[3]" => "const int *x" is extended recursively for arrays with more dimensions. ("int x[3][5]" => "const int *x[3]"). Meaning that a two dimensioned array is actually a one dimensioned array of int *'s to one dimensioned arrays of ints. This builds as you build deeper levels of indexing. My contention is that this *forces* row-order storage of arrays, (at least in the old notion of arrays). This actually is a qualitatively different way of thinking about arrays that isn't quite compatible with older ways of thought. > It is possible to pass variant-sized arrays in C by passing an array of > pointers to arrays, or by simulating a 2-dimensional array by means of a > one-dimensional one (handling the subscript computation with a #define > or a subroutine would be easiest here). But I would like to see this > simple feature added to C; I doubt it would break any existing programs. Why is this important? The compiler doesn't need to know how big arrays are, it has a pointer to its base and the size of each element. Only if the compiler is doing code for range bounds checking would that be important. Otherwise the code can be written to check array bounds by hand. (allowing for more efficient bounds checking. Rather than it being done for each reference it only has to be done for *unsure* references.) You are already passing in the size of the array..... so your calling program doesn't change. Break existing programs? Any program that is referencing outside the bounds of an array is already broken, and should be shot on sight. :-) (unless it can give good reason for behaving in such a manner). > D Gary Grady, Duke University Computation Center (dgary@ecsvax) > {...!(ihnp4,decvax,etc)!mcnc!ecsvax!dgary} > -- > D Gary Grady > Duke University Computation Center, Durham, NC 27706 > (919) 684-4146 > USENET: {decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary [why do people sign things twice?] --:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:- David Herron; ARPA-> "ukma!david"@ANL-MCS (Try the arpa address w/ and w/o the quotes, I have had much trouble with both.) UUCP -:--:--:--:--:--:--:--:--:- (follow one of these routes) {ucbvax,unmvax,boulder,research} ! {anlams,anl-mcs} -----\ vvvvvvvvvvv >-!ukma!david {cbosgd!hasmed,mcvax!qtlon,vax135,mddc} ! qusavx -----/ ^^^^^^^^^^^