home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / cplus / 2103 < prev    next >
Encoding:
Text File  |  1993-01-22  |  2.2 KB  |  40 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!slsvaat!us-es.sel.de!reindorf
  3. From: reindorf@us-es.sel.de (Charles Reindorf)
  4. Subject: Re: Use of nested functions
  5. Message-ID: <1993Jan22.081555.12027@us-es.sel.de>
  6. Sender: news@us-es.sel.de
  7. Organization: SEL-Alcatel Line Transmission Systems Dept. US/ES
  8. References: <1993Jan9.182938.16874@ucc.su.OZ.AU> <1993Jan11.215111.11291@qualcomm.com> <ll6jfhINN6n3@exodus.Eng.Sun.COM> <1993Jan13.174051.21288@ucc.su.OZ.AU> <9302002.3172@mulga.cs.mu.OZ.AU>
  9. Date: Fri, 22 Jan 93 08:15:55 GMT
  10. Lines: 28
  11.  
  12. On the subject of "trampolenes" in the implementation of nested functions, this 
  13. presumably means the following appraoch:
  14.  
  15. Suppose a function g is nested inside a function f; Any pointer to the function
  16. "g" is simply a pointer to a small "trampolene" compiled by function f into it's
  17. own stack frame. The "trampolene" code adds an extra parameter to the parameters
  18. for function "g" and then calls the real body of function "g" which is already
  19. compiled into the code section. The extra parameter point's to f's stack frame
  20. so that g can access "f"s instance variables.
  21.  
  22. Some people say that they "don't like" trampolenes, but don't seem to give any
  23. reason for it. The main objection I can see is that on some operating systems
  24. you are not allowed to do any run-time code generation. But there again, in 
  25. these architectures there do exist other, addmittedly less efficient workarounds
  26. to this problem, surely.
  27.  
  28. Other people talk about "bound" functions which presumably means that given an
  29. object a of class A with member function f, then "a.f" can be regarded as a new
  30. function (whose pointer can be taken) with a non member-function signature. The 
  31. only way I can see of using a trampolene appraoch for this situation is to place
  32. the trampolene for the function a.f into the object a itself. This increases
  33. the memory overhead for function a. In fact, the compiler would have to do
  34. this by default for every member function of a, because it won't know in
  35. advance which will be bound (without ghastly extensions to the language). This
  36. surely makes member function closures an impracticable and unworkable addition
  37. to the language?
  38.  
  39. -- Charles Reindorf
  40.