home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / cplus / 2023 < prev    next >
Encoding:
Text File  |  1993-01-10  |  2.8 KB  |  59 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!taumet!mike
  3. From: mike@taumet.com (Mike Ball)
  4. Subject: Re: Use of nested functions (Was: Proposal for default scope)
  5. Message-ID: <1993Jan10.192902.15011@taumet.com>
  6. Organization: TauMetric Corporation
  7. References: <9300817.11209@mulga.cs.mu.OZ.AU> <1993Jan8.192906.2342@qualcomm.com>
  8. Date: Sun, 10 Jan 1993 19:29:02 GMT
  9. Lines: 48
  10.  
  11. greg@qualcom.qualcomm.com (Greg Noel) writes:
  12.  
  13. >If you look at what a compiler must do to implement this, it has to create
  14. >a ``structure'' (the stack frame) that contains all the local variables,
  15. >the parameters, and so forth, and arrange for the nested function to be
  16. >able to find that structure with a sort of implicit ``this'' pointer.  In
  17. >a heavily optimizing compiler that keeps many values in registers, it can
  18. >be costly to have to re-sync memory every time a nested function _might_
  19. >be invoked.
  20.  
  21. Since you always have the full text of the nested function available, and
  22. you know exactly which variables it references, and you know exactly which
  23. function calls might call it, this cost is borne only when it is actually
  24. needed.
  25.  
  26. >On top of that, if you wish a function to retain its scope during a potentially
  27. >recursive invocation, it means that the implicit ``this'' pointer must be
  28. >kept as a part of the pointer, which would increase the size of _every_
  29. >pointer, whether the feature is used or not.  That was a real killer for
  30. >PL/I function pointers and very much against the C philosophy.
  31.  
  32. Only function pointers, of course.  For those who hate this cost, the
  33. GCC approach of generating a helper function on the stack works well.  Then
  34. you pay a slightly higher cost for the invocation, but only when it is
  35. actually necessary.
  36.  
  37. >(BTW, I'd like to have nested functions, but I would not make pointers to
  38. >them be compatible with a ``normal'' function pointer.  Nested functions
  39. >are handy to improve the clarity of code, but I'd want the compiler to
  40. >have total knowledge over when they were invoked and allow it to optimize
  41. >them as it saw fit, so that it could inline them or use special lightweight
  42. >calling sequences if it wished.
  43.  
  44. It's not a compiler problem.  The compiler has all of the knowledge
  45. it needs.  It's pretty hard to inline a function through a pointer, though.
  46.  
  47. The arguments against nested functions are primarily based on compatibility
  48. with C and on not making unnecessary changes to the language.  Implementation
  49. costs in the generated code are quite small, and are paid only when needed.
  50. Pointers to nested functions also add yet another area of undefined
  51. behavour, just like pointers to local variables.
  52.  
  53. I find that my style of programming in C++ pretty much (but not entirely)
  54. eliminates the desire for nested functions as lexical closures, so I won't
  55. argue for them very strongly.
  56. -- 
  57. Michael S. Ball (mike@taumet.com)
  58. TauMetric Corporation
  59.