home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / cplus / 18673 < prev    next >
Encoding:
Internet Message Format  |  1993-01-04  |  1.8 KB
  1. Path: sparky!uunet!spool.mu.edu!olivea!pagesat!spssig.spss.com!uchinews!msuinfo!pacific.cps.msu.edu!baldwin
  2. From: baldwin@cps.msu.edu (Reid A Baldwin)
  3. Newsgroups: comp.lang.c++
  4. Subject: eliminating automatic calls to member destructors
  5. Message-ID: <1i9qlgINNdnp@msuinfo.cl.msu.edu>
  6. Date: 4 Jan 93 17:03:44 GMT
  7. Sender: baldwin@pacific.cps.msu.edu (Reid A Baldwin)
  8. Organization: Dept. of Computer Science, Michigan State University
  9. Lines: 25
  10. NNTP-Posting-Host: pacific.cps.msu.edu
  11.  
  12. I am implementing a program that uses persistent objects. Some of the
  13. the classes I use have an integer delete_status member. When delete_status
  14. is 0, the object should not be deleted. My intention was to implement
  15. this feature by redefining the delete operator so that is checks the
  16. delete_status before calling the regular delete operator, and doesn't call
  17. it if delete_status is 0. That works fine. However, the destructors are
  18. automatically being called for each of the data members of the class.
  19. Some of these data members call delete for parts of their data structures.
  20. So, some of the data structure gets deleted anyway.
  21.  
  22. I could find an in-elegant solution by associating another delete_status
  23. member with each of the data members that call delete. Setting them all
  24. correctly seems quite error prone. Also, if someone derives classes from
  25. my classes and they add data members with destructors that call delete,
  26. they would have to know about maintaining a delete_status. This solution
  27. doesn't satisfy me.
  28.  
  29. Instead, I would like to avoid the calls to the member destructors in
  30. the first place. I don't know how to communicate this to the compiler so
  31. it doesn't insert them automatically after each return. Is there some kind
  32. of super-return statement that doesn't automatically destroy the members?
  33.  
  34. Thanks for any help,
  35. Reid Baldwin
  36. baldwin@cps.msu.edu
  37.