home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / misc / 3592 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  2.9 KB
  1. Path: sparky!uunet!ukma!usenet.ins.cwru.edu!agate!apple!decwrl!contessa!mwm
  2. From: mwm@contessa.palo-alto.ca.us (Mike Meyer)
  3. Subject: Re: Pointers
  4. Newsgroups: comp.lang.misc
  5. Distribution: world
  6. References: <mwm.2lit@contessa.palo-alto.ca.us> <BxJ39L.LCv@mentor.cc.purdue.edu> <mwm.2lp7@contessa.palo-alto.ca.us> <BxJzzv.4H7@mentor.cc.purdue.edu>
  7. X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52
  8. Keywords: 
  9. Summary: 
  10. Message-ID: <mwm.2lx7@contessa.palo-alto.ca.us>
  11. Date: 11 Nov 92 09:26:04 PST
  12. Organization: Missionaria Phonibalonica
  13. Lines: 49
  14.  
  15. In <BxJzzv.4H7@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) wrote:
  16. > In article <mwm.2lp7@contessa.palo-alto.ca.us> mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:
  17.  
  18. This all started when herman said:
  19. > >> >> You need explicit pointers to functions when the caller does not know
  20. > >> >> the name of the function being called, but the caller has received a
  21. > >> >> pointer to the function.
  22.  
  23. > >> I will consider any suggestions to do this in a better manner, but I
  24. > >> am not willing to make it any less flexible, nor to put any more burdens
  25. > >> on the writers of the subprogram, nor of the (usually separately compiled)
  26. > >> fill functions.
  27. > 
  28. > >You want to make it better? Two things you can do. First, throw away
  29. > >the silly attachment to pointers per se, and let the compiler handle
  30. > >the trivia. When you call a function with a function as an argument,
  31. > >you give it the name of the function as the argument. When you receive
  32. > >a function as an argument, you declare it - AND USE IT - as a
  33. > >function. That means you can drop the extra "*" on the call, and on
  34. > >the reference to the function in the call. No explicit pointers
  35. > >needed; they are all implicit, and might not be there at all,
  36. > >depending on how good your compiler is.
  37. > 
  38. > The function is not an argument to something else.  I do not see how 
  39. > the code will run any better if we have to use something like
  40. > 
  41. >     superfill(*fl,*des)
  42. > 
  43. > than what I have suggested.
  44.  
  45. Herman, the code probably won't _run_ any better. It will never run
  46. any worse, as a "dumb" implementation would map it directly back to
  47. the pointers you used. The point is that your original statement -
  48. about needing explicit pointers - is _wrong_. I know it's wrong; I do
  49. just what you're talking about in a language with no explicit pointers
  50. all the time. The original code I posted showed such a case exactly. I
  51. apologize for using identifiers that made things clearer instead of
  52. your favorite one-letter-with-no-relation-to-the-problem style.
  53.  
  54. > So just as many pointers are used, anyhow.
  55.  
  56. That's for the dumb compiler, or the worst-case for the smart
  57. compiler. By getting rid of the explicit pointers, you make it
  58. possible for a compiler to notice cases where all the functions being
  59. passed in are known, and to generate better code to take advantage of
  60. that.  In the extreme case, only one such function is used, and a good
  61. compiler will generate inline code for it.
  62.  
  63.     <mike
  64.