home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / cplus / 2015 < prev    next >
Encoding:
Text File  |  1993-01-08  |  2.6 KB  |  59 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!ames!pacbell.com!network.ucsd.edu!qualcom.qualcomm.com!harvey.qualcomm.com!greg
  3. From: greg@harvey.qualcomm.com (Greg Noel)
  4. Subject: Re: Use of nested functions (Was: Proposal for default scope)
  5. Message-ID: <1993Jan9.040554.3064@qualcomm.com>
  6. Sender: news@qualcomm.com
  7. Nntp-Posting-Host: harvey.qualcomm.com
  8. Organization: Qualcomm, Inc., San Diego, CA
  9. References: <lkrt9oINNjq2@exodus.Eng.Sun.COM>
  10. Date: Sat, 9 Jan 1993 04:05:54 GMT
  11. Lines: 46
  12.  
  13. David Chase <chased@rbbb.Eng.Sun.COM> writes:
  14. >This is not correct.  Nested functions are not expensive to implement.
  15.  
  16. OK, how do you do it so that:
  17.      o    It's efficient enough on a wide class of architectures that I don't
  18.     care about the overhead involved in using it.
  19.      o    There is no penalty for _not_ using it.
  20.      o    It invokes the subroutine in the context where its address was
  21.     evaluated, even under recursion.
  22.      o    It's thread-safe; that is, the compiler doesn't create any global
  23.     variables or the like behind my back.
  24.      o    The address of the function is compatible with a ``standard''
  25.     function variable.
  26.  
  27. Note that if you can do this, it would be possible to bind a non-static class
  28. member function and a class object together, assign that to a ``standard''
  29. function variable, and arrange that when the function variable was invoked,
  30. the class member function would be invoked on the object.  The mechanisms
  31. involved are equivalent.
  32.  
  33. >I speak as someone who has done it.
  34.  
  35. Well, I haven't done it myself, but in a previous incarnation I got to grovel
  36. through a lot of PL/I code that used the equivalent of function pointers.  The
  37. code generated on an IBM/360 was astoundingly inefficient.
  38.  
  39. Of course, one can't make a general argument from one data point, but if
  40. function pointers are that expensive on a not-unreasonable architecture,
  41. you'll have to convince me that they can be considered ``inexpensive''
  42. in the general case.  I'm willing to be proven wrong, but it will take
  43. more than just an assertion that it can be done.
  44.  
  45. >Compared to the costs of programming, and the potential wins ... nested
  46. >functions are a clear win.
  47.  
  48. Don't get me wrong---I would like to have nested functions.  But the same
  49. logic that prevented the adoption of an exponention operator is in effect
  50. here: it can be ``unexpectedly'' costly.
  51.  
  52. >>The ``Spirit of C'' ... ; C++ inherits much of this spirit.
  53. >Is this good or bad?
  54.  
  55. It's neither good nor bad; it just is.  But it must be understood when
  56. considering how the language is put together.
  57. -- 
  58. -- Greg Noel, Unix Guru         greg@qualcomm.com  or  greg@noel.cts.com
  59.