home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 19657 < prev    next >
Encoding:
Text File  |  1993-01-21  |  1.4 KB  |  24 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!spool.mu.edu!agate!stanford.edu!kronos.arc.nasa.gov!butch!netcomsv!netcom.com!erc
  3. From: erc@netcom.com (Eric Smith)
  4. Subject: Re: Dangling pointers & suggestions on future implementations of "delete"
  5. Message-ID: <1993Jan21.083428.10058@netcom.com>
  6. Organization: Netcom - Online Communication Services (408 241-9760 guest)
  7. References: <Jan18.210305.21697@yuma.ACNS.ColoState.EDU> <1993Jan19.193048.15022@borland.com> <1993Jan20.213807.20740@cbnewsi.cb.att.com>
  8. Date: Thu, 21 Jan 1993 08:34:28 GMT
  9. Lines: 13
  10.  
  11. In article <1993Jan20.213807.20740@cbnewsi.cb.att.com> rhw@att.com (Robert Wentworth) writes:
  12. >Anyone else have nifty techniques that they use to root out memory
  13. >problems?
  14.  
  15. My memory allocation function keeps track of the amount of memory it has
  16. allocated and the amount it has freed.  When the program exits normally,
  17. it verifies that the amount of memory freed equals the amount allocated,
  18. and issues a warning if not.  I have this feature turned on at all times
  19. during development, not just for debugging memory allocation problems.
  20. So if I add a new feature that happens to have a memory leak in it, I find
  21. out right away, even if it has been months or years since my last memory
  22. leak.  And the cost is insignificant, such that it wouldn't hurt even if
  23. I left it turned on in a delivered application.
  24.