home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / fortran / 3041 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  3.7 KB
  1. Path: sparky!uunet!ogicse!uwm.edu!linac!unixhub!slacvx.slac.stanford.edu!fairfield
  2. From: fairfield@slacvx.slac.stanford.edu
  3. Newsgroups: comp.lang.fortran
  4. Subject: Re: Fortran 90:  Pointers to Functions?
  5. Message-ID: <1992Aug14.103217.1@slacvx.slac.stanford.edu>
  6. Date: 14 Aug 92 18:32:17 GMT
  7. Article-I.D.: slacvx.1992Aug14.103217.1
  8. References: <166htnINNhvn@darkstar.UCSC.EDU> <1693l7INNn4o@darkstar.UCSC.EDU> <16gp3nINNbm8@darkstar.UCSC.EDU>
  9. Sender: news@unixhub.SLAC.Stanford.EDU
  10. Organization: Stanford Linear Accelerator Center
  11. Lines: 80
  12. Nntp-Posting-Host: slacvx.slac.stanford.edu
  13.  
  14. In article <16gp3nINNbm8@darkstar.UCSC.EDU>, sla@fast.ucsc.edu (Steve Allen) writes:
  15. > In article <1693l7INNn4o@darkstar.UCSC.EDU> sla@fast.ucsc.edu I wrote:
  16. >>[Fortran 77 & 90 do not have anything like C's "pointer to a function"]
  17. >>Is there some other (reasonably elegant) method for getting this kind of
  18. >>functionality in Fortran 90?
  19. > 
  20. > This is an example of what I would like to be doing with pointers to functions
  21.  
  22.     [example deleted]
  23.  
  24. > Then, the thing that I would like to be able to do, which can be expressed
  25. > in many fewer lines of code.
  26. >     SUCCESS = .FALSE.
  27. >     I = 0
  28. > 100     CONTINUE
  29. >     IF (.NOT. SUCCESS) THEN
  30. >         IF (I .LT. 459) THEN
  31. >         I = I + 1
  32. >         IF (STATE .EQ. KNOWNSTATE(I)) THEN
  33. >             CALL {the Ith function, we have no syntax for this}
  34. >             SUCCESS = .TRUE.
  35. >         ENDIF
  36. >         GOTO 100
  37. >         ELSE
  38. >         CALL REPORT_UNKNOWN_STATE(STATE)
  39. >         ENDIF
  40. >     ENDIF
  41. > 
  42. > Furthermore, with some kind of array of pointers to functions, I could
  43. > exchange one function in the array for another during the execution of
  44. > the program.  Basically, the user pushes some button, and the program
  45. > starts behaving differently because it is calling different functions
  46. > in response to the user's input.
  47.  
  48.     Well, you _can_ do this with VAX Fortran ("Gurgle!"...to quote an earlier,
  49. unrelated posting... ;-).
  50.  
  51.     Turns out that in about 1981 when the LBL side of our collaboration
  52. starting writing the analysis code for my thesis experiment, they said, 
  53. "Hey! We don't have to use those _ugly_ DUMMY subroutines, we can just 
  54. store that addresses of the subroutines the user actually wants called in 
  55. an array, and pass the array value to a subroutine which calls the subroutine!
  56. So Eleagant!"  (So obscure to the uninitiated...but flexible...)
  57.  
  58.     It works in two steps:  the user writes an INIT subroutine which has
  59. a bunch of statements like (structure is simplified here):
  60.  
  61.     SUB_ARRAY(NEXT) = %LOC(THE_NEXT_SUBROUTINE_I_WANT_CALLED)
  62.     NEXT = NEXT+1
  63.  
  64. The %LOC built-in stored the address of THE_NEXT_SUBROUTINE_I_WANT_CALLED
  65. in array SUB_ARRAY.  Then from the main program there was a loop something
  66. like:
  67.  
  68.     DO I=1,LAST_SUB
  69.         CALL DO_SUB(%VAL(SUB_ARRAY(I))
  70.     ENDDO
  71.  
  72. in which the %VAL built-in passed the _value_ stored in SUB_ARRAY(I) to
  73. DO_SUB (rather than the address of SUB_ARRAY(I) ), and DO_SUB was something
  74. like:
  75.     SUBROUTINE DO_SUB(SUBR)
  76.     CALL SUBR()
  77.     RETURN
  78.     END
  79.  
  80.     Sorry to be so long-winded here, but I just couldn't resist giving an
  81. example that appears to match exactly what Steve is trying to do ;-)   In
  82. fact, I'd like to here from some of the compiler experts out there why
  83. something like this couldn't easily (relatively speaking) be made standard
  84. given that it has been possible to pass functions to subprograms for a long
  85. time?  Is it just committee politics?
  86.  
  87.     Cheers, Ken
  88. -- 
  89.  Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slacvx.Slac.Stanford.Edu
  90.  SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
  91.  Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
  92.  ----------------------------------------------------------------------------
  93.  These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
  94.