home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12755 < prev    next >
Encoding:
Text File  |  1992-08-21  |  2.3 KB  |  53 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mole-end!mat
  3. From: mat@mole-end.matawan.nj.us
  4. Subject: Re: Garbage Collection for C++
  5. Message-ID: <1992Aug21.082840.3703@mole-end.matawan.nj.us>
  6. Organization: :
  7. References: <1992Aug6.014619.2111@ucc.su.OZ.AU> <DAVEG.92Aug20043156@synaptx.synaptics.com>
  8. Date: Fri, 21 Aug 1992 08:28:40 GMT
  9. Lines: 42
  10.  
  11. In article <DAVEG.92Aug20043156@synaptx.synaptics.com>, daveg@synaptics.com (Dave Gillespie) writes:
  12. > In article <1992Aug19.180252.12942@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
  13.  
  14. > >>   Is there really so much harm in allowing the C++ runtime
  15. > >>   system to delete the object in that circumstance?
  16. > 
  17. > > You've answered your own question in the negative.  If the destructor
  18. > > has an effect on the program's output, and it is accidentally called
  19. > > by the GC instead of by its proper deletion, the program's output will
  20. > > depend on the exact properties of the GC system and ...
  21.  
  22. > Sorry, I didn't make myself clear.  I realize that allowing GC to call
  23. > a destructor would add one more case where destructors with side effects
  24. > could surprise the C++ programmer.  My question was, is that potential
  25. > for surprise enough to kill the idea of garbage collection in C++?
  26.  
  27. > My answer is no, it just means C++ programmers who use garbage collection
  28. > have to be a little careful about what they put in their destructors.
  29.  
  30. `A little careful about what they put in their destructors.'
  31. (Picture this said with dripping, oozing sarcasm.)
  32.  
  33. If you look at where OOA and OOD are going, and what they are talking
  34. about, you may observe that they talk about things called `relationships.'
  35. These relationships have something called `cardinality,' and they describe
  36. what does and does not exist--and in the better models, when.
  37.  
  38. To model these OOA and OOD things in OOP (as we should) we have to control
  39. what does and does not exist--or we have to fake it by introducing an
  40. indirect representation of Object existance.
  41.  
  42. I've neither seen nor heard a proposal for a workable, maintainable,
  43. practical, economical way of representing Object existance--other than
  44. object existance.  (Note the difference in capitalization, please.)
  45.  
  46. It is this that underlies almost all of the problems with databases
  47. and persistance.
  48. -- 
  49.  (This man's opinions are his own.)
  50.  From mole-end                Mark Terribile
  51.  
  52.  mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
  53.