home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / cplus / 2106 < prev    next >
Encoding:
Internet Message Format  |  1993-01-23  |  2.0 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!news2me.EBay.Sun.COM!exodus.Eng.Sun.COM!rbbb!chased
  2. From: chased@rbbb.Eng.Sun.COM (David Chase)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Use of nested functions
  5. Date: 22 Jan 1993 18:58:21 GMT
  6. Organization: Sun
  7. Lines: 33
  8. Message-ID: <lm0gudINN9be@exodus.Eng.Sun.COM>
  9. References: <1993Jan13.174051.21288@ucc.su.OZ.AU> <9302002.3172@mulga.cs.mu.OZ.AU> <1993Jan22.081555.12027@us-es.sel.de>
  10. NNTP-Posting-Host: rbbb
  11.  
  12. In article <1993Jan22.081555.12027@us-es.sel.de> reindorf@us-es.sel.de (Charles Reindorf) writes:
  13. >On the subject of "trampolenes" in the implementation of nested functions, this 
  14. >presumably means the following appraoch:
  15.  
  16. > [code generation into stack frame, which works.]
  17. > ... The main objection I can see is that on some operating systems
  18. >you are not allowed to do any run-time code generation.
  19.  
  20. One workaround is to keep a cache of trampolines, which in this case
  21. are pairs of code+data, where each piece of code is compiled to
  22. reference a particular piece of data.  Some run-time code generation
  23. must still occur.  In the limit case (the least flexible OSes) a
  24. different calling convention must be used for all function calls.
  25.  
  26. >Other people talk about "bound" functions which presumably means that
  27. >given an object a of class A with member function f, then "a.f" can be
  28. >regarded as a new function (whose pointer can be taken) with a non
  29. >member-function signature.  The only way I can see of using a
  30. >trampolene appraoch for this situation is to place the trampolene for
  31. >the function a.f into the object a itself.
  32.  
  33. Actually, you could "new" them.  Just allocate the functions on the
  34. "heap", and free them when you are done.  Or, we could take a flying
  35. leap at the slippery slope and add garbage collection.
  36.  
  37. >This surely makes member function closures an impracticable and
  38. >unworkable addition to the language?
  39.  
  40. I think the answer is another question: "compared to what?"  I'm
  41. really looking forward to run-time instantiation of templates.
  42.  
  43. David Chase
  44. Sun
  45.