home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / cplus / 1882 < prev    next >
Encoding:
Text File  |  1992-12-21  |  6.1 KB  |  125 lines

  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!mcsun!julienas!jussieu!shiva.jussieu.fr!kriss
  3. From: kriss@rock.ibp.fr (Christophe GROSJEAN)
  4. Subject: Re: C++ already *has* nested functions SO WHAT'S THE BEEF?
  5. In-Reply-To: rfg@netcom.com's message of Mon, 21 Dec 1992 08:09:52 GMT
  6. Message-ID: <KRISS.92Dec21182101@rock.ibp.fr>
  7. Sender: news@jussieu.fr (Le Facteur)
  8. Nntp-Posting-Host: rock.ibp.fr
  9. Reply-To: grosjean@masi.ibp.fr
  10. Organization: Laboratoire MASI, Paris, France.
  11. References: <1992Dec21.080952.15309@netcom.com>
  12. Date: Mon, 21 Dec 1992 17:21:01 GMT
  13. Lines: 110
  14.  
  15. In article <1992Dec21.080952.15309@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
  16.  
  17. >   You see, C++ already provides nested functions.  I believe that even the
  18. >   people who are bemoaning the lack of nested function in C++ are probably
  19. >   aware of this fact (or would be if they thought about it for a moment)
  20. >   and that in fact what we have here is a failure to communicate clearly.
  21.  
  22. Indeed C++ provide several ways of simulating nested functions,
  23. the tricks to make it works has basically the 3 problems you
  24. pointed out.
  25.  
  26.  
  27. >       o    We have to "invent" an otherwise useless and unnecessary
  28. >           containing struct, union, or class type in order to be
  29. >           able to nest functions.
  30. >
  31. >       o    Due to the (silly?) prohibition against defining a function
  32. >           member of a block-local struct, union, or class type outside
  33. >           of (and after) its "parent" type, and due to the (silly?)
  34. >           rule that says that all functions defined *within* a class
  35. >           are implicitly `inline', our nested functions are always
  36. >           necessarily `inline' (when using this technique for nesting)
  37. >           even if we do not want them to be.
  38. >
  39. >       o    Last but not least, although nested functions can legally
  40. >           reference *most* names of *most* kinds of things declared
  41. >           in a containing scope (including one local to a containing
  42. >           function) there is one small and mildly annoying exception
  43. >           to this general rule... i.e. we cannot access `auto' and
  44. >           `register' *objects* declared within a containing local
  45. >           scope.  Note that we *can* however reference the tags of
  46. >           enum, struct, union, and class, types, names declared in
  47. >           typedef statements, names of enumerators, function names,
  48. >           and names of static and extern objects which are declared
  49. >           in the containing (block) scope.
  50.  
  51.  
  52. But, there is more to say about them : 
  53.  
  54. >   For my part, I would be satisfied if the ANSI/ISO C++ committee(s) would
  55. >   add "nested functions" to C++ in such a way that the first two problems
  56. >   on my list above could be eliminated.  But note that this could be done
  57. >   with only a single minor syntax change (to allow function *definitions*
  58. >   as well as function *declarations* within a local block) and one minor
  59. >   semantic change, i.e. disallowing the mention of any name of a locally
  60. >   declared function (except those declared `extern') in any context other
  61. >   than a call to the given function.  These two minor changes would solve
  62. >   the problems I'm concernd with, and they would be relatively easy and
  63. >   painless for implementors to implement.  Also, just as importantly, they
  64. >   would not add materially to the already horrendous complexity of the
  65. >   language (which is already a terrible burden for all those who would try
  66. >   to learn this language).
  67.  
  68. Well, i merely agree with you on this, the effect would be to make a
  69. nested function declaration simpler. 
  70.  
  71. >   So why do people insist on attacking (and defeating) the third minor
  72. >   problem listed above (regardless of costs)?
  73.  
  74. >   Well, it appears that some people have this mental model of "nested
  75. >   functions" left over from the days when they programmed in Pascal, where
  76. >   *anything* in a containing scope could be accessed directly.  Sadly, these
  77. >   folks don't seem to "get" the fundamental idea which made C into the big
  78. >   success that it is today... i.e. that it is *good* when potentially
  79. >   expensive run-time actions (e.g. indirection through some number of
  80. >   "static link" pointers) are made *explicit* to the programmer so that he
  81. >   or she will be more aware of the potential effects these things may have
  82. >   upon run-time performance.
  83.  
  84. Modula-2, as I saw it (I didn't tried *all* compilers) has no reason to envy C,
  85. and particularly not the efficiency. However, scope rules are *perfectly*
  86. consistent. So much for the idea of C success strongly related to its efficiency.
  87. I use (and like) C and C++, and that's not a point. But it still seems strange
  88. to me that you speak about *explicit indirection* when C++ obviously go
  89. the other way (first step : passing vars by reference with &, second step :
  90. virtual functions). I got the feeling that C++ is often confusing about data storage
  91. and concepts.
  92.  
  93. >   Obviously, I have a strong disagreement with the folks who would (for the
  94. >   sake of eliminating a very minor restriction which only makes a difference
  95. >   in rare cases anyway) "hack" the language mercilessly (and thereby cause
  96. >   yet another headache for implementors).
  97.  
  98. About the first and second problem, it seems easy enough to change,
  99. but I think it could make the difference beetween a used feature and
  100. an unused one (as I see it now !).
  101.  
  102. I don't think the third restriction you pointed out is a minor one.
  103. For one reason : local static vars already have another meaning !
  104. Those vars are initialized only *once* when you first execute the
  105. containing function ! If you modify them the new value will stuck.
  106.  
  107. Doesn't matter in most cases. But it's a powerfull source of bugs
  108. whenever you use recursive functions. What I say is that the problem
  109. with static functions is not that they are statically allocated :
  110. no problem if I have space enough, but that they are initialized only
  111. once and won't be preserved in recursive call.
  112.  
  113. I can do what I want copying values beetween automatic and static vars,
  114. but a *user* of a library expecting a function as an argument should'nt
  115. bother about that, not saying that king of things is very error prone.
  116.  
  117. I would be perfectly happy with a *local* keyword meaning the value
  118. is stored in a static var, but is saved before calls and initialised
  119. every time my function is called : does it seem a difficult thing to do ?
  120.  
  121. I need it, I'm no maniac !
  122.  
  123. Best, regards
  124.  
  125.