Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!apple!bionet!ig!arizona!mike From: mike@arizona.edu (Mike Coffin) Newsgroups: comp.lang.fortran Subject: Re: Fortran versus C for numerical anal Message-ID: <7142@megaron.arizona.edu> Date: 21 Sep 88 18:09:11 GMT References: <3746@lanl.gov> Organization: U of Arizona CS Dept, Tucson Lines: 56 From article <3746@lanl.gov>, by jlg@lanl.gov (Jim Giles): > No, I still like the Fortran 8x stuff better: > > ALLOCATABLE, CHARACTER::TWODARRAY(:,:) > ... > ALLOCATE (TWODARRAY(10,10)) > ... > TWODARRAY(5,9) = 'c' > This seems ugly to me, for several reasons. (1) If FORTRAN ever gets pointers, there will presumably be two entirely separate ways of allocating arrays --- ALLOCATE and new/release, or alloc/dealloc, or whatever they're called. They will both do essentially the same thing; only the syntax will be different. (2) Although the above manages (barely) to avoid introducing pointers, it suffers from almost all the problems that pointers have. You cannot easily tell if TWODARRAY is "attached" (oops; I almost slipped and said "points to") to a real array, and if so what the dimensions are. Moreover, the dimensions can potentially be specified in many places; thus you have to trace the execution path to determine what the current bounds are. (3) Since the array associated with TWODARRAY does not follow the normal scope rules, ALLOCATE must use a very general allocation scheme --- something along the lines of C's malloc(). For instance, the array cannot be allocated on the stack, since the current stack frame may disappear before the array is deallocated. (4) There is a much cleaner way to do this. Allow declarations wherever there are statements, and allow arrays to be declared with general expressions as bounds. E.g., in SR we can say var a, b: int read(a,b) var twodarray[1:a, 1:b]: char The declaration remains in effect until the end of the block where it is declared. Twodarray *is* an array anywhere it is visible. The bounds can be determined by looking at the declaration. On most machines, it can be allocated by adjusting the stack pointer, since the array disappears when the current block does. (Of course, if the bounds are constant, it is allocated statically.) And finally, if you really need to declare arrays that don't follow normal scope rules, you use pointers and new/release. Thus there is one way to get objects that follow normal scope rules (declarations) and one way to get objects with indefinite life-times (new/release). The need for arrays that don't follow normal scope rules is rare, and the explicit pointers remind you of the possible problems. -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2,ihnp4}!arizona!mike Tucson, AZ 85721 (602)621-2858