home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / cplus / 1889 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.9 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!news2me.EBay.Sun.COM!exodus.Eng.Sun.COM!rbbb.Eng.Sun.COM!chased
  2. From: chased@rbbb.Eng.Sun.COM (David Chase)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: C++ already *has* nested functions SO WHAT'S THE BEEF?
  5. Date: 22 Dec 1992 00:49:22 GMT
  6. Organization: Sun
  7. Lines: 60
  8. Message-ID: <ljcpgiINNpdg@exodus.Eng.Sun.COM>
  9. References: <1992Dec21.080952.15309@netcom.com>
  10. NNTP-Posting-Host: rbbb
  11. Keywords: nested functions, dumb ideas
  12.  
  13. rfg@netcom.com (Ronald F. Guilmette) writes:
  14. >So what is it that people are complaining about?
  15.  
  16. >    o    [fake] nested functions ... cannot access `auto' and
  17. >        `register' *objects* declared within a containing local
  18. >        scope.  
  19.  
  20. >I believe that it is this last item that concerns people the most.
  21.  
  22. This is true.  The rest is all largely syntatic fluff.  Fluff is nice,
  23. but that is not what people are asking for here.
  24.  
  25. > ... when I hear about
  26. >all of these complicated schemes for supporting dynamic "up-level addressing"
  27.  
  28. It was easy.  We did it for Modula-3, two different ways.
  29.  
  30. >and also such things as "special" kinds of function pointers for holding
  31. >pointers to nested function
  32.  
  33. This is not necessary at all.  See previous post for details on how to
  34. avoid special function pointer representations for nested functions.
  35.  
  36. >(and a special new syntax for declaring such things) 
  37.  
  38. Not necessary.
  39.  
  40. >Haven't the implementors already got enough to do??  
  41.  
  42. Yes, we do.  On the other hand, if you look at in terms of costs and
  43. benefits, especially in comparision to the rest of the language, this
  44. is a relative win.  If you look at it in terms of percentage of total
  45. work, this is also not a big deal.
  46.  
  47. >Can't people figure out how to simply pass any needed `auto' variables
  48. >which are local to the containing function as additional actual
  49. >argument to the nested (called) function on those very rare occasions
  50. >when this is actually necessary??  I mean what the devil is the
  51. >problem here?
  52.  
  53. You're not getting the picture here.  If I declare (to choose a common
  54. and perhaps over-simple example) a bag-object with an iterator
  55. interface that takes a function-to-be-applied-to-each as a parameter,
  56. then it just takes a function, period.  It doesn't matter if it needs
  57. 0, 1, 2, or many pointers to auto variables passed to it.  This
  58. simplifies the interface, and has the advantage of not adding clutter
  59. (e.g., explicit state variables to be passed in and out of the
  60. function) where it is not needed.
  61.  
  62. >I mean c'mon folks... This endless "featurism" has got to stop somewhere!
  63.  
  64. I agree, but I think we mean different things.  C++ has many features
  65. that I still haven't figured out how to use, or even if they are in
  66. fact useful.  It has many of other features that I put in the "plenty
  67. of rope" category (be careful not to wrap it round your neck).  Nested
  68. functions, I know how to use, and I know how they can be used to
  69. simplify interfaces, and they are not especially "dangerous".
  70.  
  71. David Chase
  72. Sun
  73.