home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / cplus / 2010 < prev    next >
Encoding:
Text File  |  1993-01-08  |  3.0 KB  |  56 lines

  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!network.ucsd.edu!qualcom.qualcomm.com!qualcom.qualcomm.com!greg
  3. From: greg@qualcom.qualcomm.com (Greg Noel)
  4. Subject: Use of nested functions (Was: Proposal for default scope)
  5. Message-ID: <1993Jan8.192906.2342@qualcomm.com>
  6. Sender: news@qualcomm.com
  7. Nntp-Posting-Host: qualcom.qualcomm.com
  8. Organization: Qualcomm, Inc., San Diego, CA
  9. References: <9300817.11209@mulga.cs.mu.OZ.AU>
  10. Date: Fri, 8 Jan 1993 19:29:06 GMT
  11. Lines: 43
  12.  
  13. Fergus James HENDERSON <fjh@munta.cs.mu.OZ.AU> writes:
  14. >Many people seem to think that the purpose of nested functions is purely
  15. >as encapsulation, a sort of code organization/modularization feature.
  16. >... the real reason that they are useful is that ... their addresses can
  17. >be passed to any function that just expects a function parameter.
  18. >If a local function never has its address taken, then it does not use
  19. >the full power of nested functions.
  20.  
  21. This is a valid point, but this is exactly the part that is expensive to
  22. implement.  The ``Spirit of C'' is that expensive things are exposed to
  23. the programmer; C++ inherits much of this spirit.
  24.  
  25. If you look at what a compiler must do to implement this, it has to create
  26. a ``structure'' (the stack frame) that contains all the local variables,
  27. the parameters, and so forth, and arrange for the nested function to be
  28. able to find that structure with a sort of implicit ``this'' pointer.  In
  29. a heavily optimizing compiler that keeps many values in registers, it can
  30. be costly to have to re-sync memory every time a nested function _might_
  31. be invoked.
  32.  
  33. On top of that, if you wish a function to retain its scope during a potentially
  34. recursive invocation, it means that the implicit ``this'' pointer must be
  35. kept as a part of the pointer, which would increase the size of _every_
  36. pointer, whether the feature is used or not.  That was a real killer for
  37. PL/I function pointers and very much against the C philosophy.
  38.  
  39. (BTW, I'd like to have nested functions, but I would not make pointers to
  40. them be compatible with a ``normal'' function pointer.  Nested functions
  41. are handy to improve the clarity of code, but I'd want the compiler to
  42. have total knowledge over when they were invoked and allow it to optimize
  43. them as it saw fit, so that it could inline them or use special lightweight
  44. calling sequences if it wished.  If a pointer syntax is needed, I'd make
  45. it similar to the C++ class pointer notation, using the function name as
  46. the class---after all, that's really what's going on....)
  47.  
  48. But, as others have pointed out, it's possible for you, the programmer, to
  49. do the expensive thing that the compiler would have to do, by putting the
  50. variables you need in a structure and keeping a pointer to it where the
  51. helper function can find it.  I won't claim that it's fun to do it this
  52. way, but this is essentially what the compiler would have to generate, so
  53. the overhead would be the same.
  54. -- 
  55. -- Greg Noel, Unix Guru         greg@qualcomm.com  or  greg@noel.cts.com
  56.