home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / cplus / 2147 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.1 KB
  1. Path: sparky!uunet!seismo!darwin.sura.net!gatech!rpi!batcomputer!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: Compiler should generate virtual destructors
  5. Message-ID: <1993Jan26.225409.11089@ucc.su.OZ.AU>
  6. Date: 26 Jan 93 22:54:09 GMT
  7. References: <harvey.727664973@regina> <24679@alice.att.com> <1993Jan23.081616.29910@us-es.sel.de>
  8. Sender: news@ucc.su.OZ.AU
  9. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  10. Lines: 53
  11. Nntp-Posting-Host: extro.ucc.su.oz.au
  12.  
  13. In article <1993Jan23.081616.29910@us-es.sel.de> reindorf@us-es.sel.de (Charles Reindorf) writes:
  14. >|> Actually, you could "new" them.  Just allocate the functions on the
  15. >|> "heap", and free them when you are done.  Or, we could take a flying
  16. >|> leap at the slippery slope and add garbage collection.
  17. >
  18. >Again, as you say, you have to free them "when you are done", but in 
  19. >this situation, there is no natural idea of "when you are done". In 
  20. >fact, whereas the natural lifetime of a nested function is until the 
  21. >containing function completes, the natural lifetime of a bound function 
  22. >is until the destruction of the object to which it is bound. How do you 
  23. >ensure that whenever an object dies, that bound function trampolenes 
  24. >which *might* have been generated for it are deleted? 
  25.  
  26.     The compiler doesn't bother to try. Leave it up to the programmer.
  27. Nothing new here :-) After all, just killing the trampoline doesn't stop 
  28. you calling it through the pointer you still have lying around.
  29.  
  30. >I can see no way that the solution can be implemented in a way that 
  31. >doen't impact the normal performance of the system. 
  32.  
  33.     Just leave deletion of the trampoline up to the programmer
  34. like all other dynamically created objects.
  35.  
  36. >
  37. >None of this detracts from the fact that *nested* functions *can* be 
  38. >implemented without impacting on the normal performance of the system, 
  39. >and without requiring any special new constructs in the language (more 
  40. >a relaxation of a rule). What's more, they are extremely valid for 
  41. >situations where iterators are used for many general call-back 
  42. >mechanisms which are considerably more awkward (or unsafe) when done 
  43. >using one of the manual alternatives.
  44.  
  45.     Yes, callbacks are a compelling argument. Must
  46. remember this for the proposal.
  47. >
  48. >Moreover, if nested functions are implemented, they imply an easy 
  49. >manual solution to many cases where bound member functions might have 
  50. >been required. Other cases where bound member functions might be 
  51. >required can surely be solved through abstract base classes and in some 
  52. >cases MI.
  53.  
  54.     But the bound members can be had easily
  55. IF we have trampolines for the nested functions, without
  56. any more loss of safety than you get with ordinary pointers.
  57. (Although the effects of executing non-existant code,
  58. or existant code for non-existant objects will be nasty,
  59. if you dont like it --- dont use it)
  60.  
  61. -- 
  62. ;----------------------------------------------------------------------
  63.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  64.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  65. ;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------
  66.