home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / cplus / 2132 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.0 KB
  1. Path: sparky!uunet!ogicse!cs.uoregon.edu!sgiblab!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  2. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Use of nested functions
  5. Message-ID: <1993Jan26.224107.9187@ucc.su.OZ.AU>
  6. Date: 26 Jan 93 22:41:07 GMT
  7. Article-I.D.: ucc.1993Jan26.224107.9187
  8. References: <1993Jan13.174051.21288@ucc.su.OZ.AU> <9302002.3172@mulga.cs.mu.OZ.AU> <1993Jan22.081555.12027@us-es.sel.de>
  9. Sender: news@ucc.su.OZ.AU
  10. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  11. Lines: 56
  12. Nntp-Posting-Host: extro.ucc.su.oz.au
  13.  
  14. In article <1993Jan22.081555.12027@us-es.sel.de> reindorf@us-es.sel.de (Charles Reindorf) writes:
  15. >On the subject of "trampolenes" in the implementation of nested functions, 
  16. >this >presumably means the following appraoch:
  17. >
  18. >Some people say that they "don't like" trampolenes, but don't seem to give any
  19. >reason for it. 
  20.  
  21.     Separation of code and data is an important machine
  22. principle for safety. Some machines (all the good ones :-) do not
  23. allow executing things in the data area.
  24.  
  25.     Trampolines feel a bit like the Cobol ALTER statement:
  26. dangerous hacks.
  27.  
  28. >The main objection I can see is that on some operating systems
  29. >you are not allowed to do any run-time code generation. 
  30.  
  31.     Some OS may not grant the user the priviledges required
  32. to generate and execute code on the fly. This is because
  33. it is close to 'self-modifying' code, which is not
  34. generally considerd very safe.
  35.  
  36. >But there again, in 
  37. >these architectures there do exist other, 
  38. >addmittedly less efficient workarounds
  39. >to this problem, surely.
  40.  
  41.     Such as? I would LOVE to hear of one that did not require
  42. the standard C/C++ function pointers to double in size.
  43.  
  44. >
  45. >Other people talk about "bound" functions which presumably means that given an
  46. >object a of class A with member function f, then "a.f" can be regarded as a new
  47. >function (whose pointer can be taken) with a non member-function signature. The 
  48. >only way I can see of using a trampolene appraoch for this situation is to place
  49. >the trampolene for the function a.f into the object a itself. This increases
  50. >the memory overhead for function a. In fact, the compiler would have to do
  51. >this by default for every member function of a, because it won't know in
  52. >advance which will be bound (without ghastly extensions to the language). This
  53. >surely makes member function closures an impracticable and unworkable addition
  54. >to the language?
  55. >
  56.  
  57.     No, one can just leave it up to the user to delete the
  58. trampoline---as for other dynamically allocated objects. It is not
  59. as 'safe' as puting the trampoline in the object (or a pointer thereto),
  60. but even that isnt safe (the trampoline could still be called
  61. after it was deleted --- very nasty crash following, perhaps sometime
  62. later).
  63.  
  64.  
  65. -- 
  66. ;----------------------------------------------------------------------
  67.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  68.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  69. ;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------
  70.