home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16729 < prev    next >
Encoding:
Text File  |  1992-11-22  |  1.9 KB  |  42 lines
  1. Newsgroups: cvnet.c++,comp.lang.c++
  2. Path: sparky!uunet!taumet!steve
  3. From: steve@taumet.com (Steve Clamage)
  4. Subject: Re: Finding memory leaks
  5. Message-ID: <1992Nov22.181937.2176@taumet.com>
  6. Keywords: OOP,memory leaks
  7. Organization: TauMetric Corporation
  8. References: <1992Nov20.191828.14500@ultb.isc.rit.edu>
  9. Date: Sun, 22 Nov 1992 18:19:37 GMT
  10. Lines: 30
  11.  
  12. mpk9172@ultb.isc.rit.edu (M.P. Kirby) writes:
  13.  
  14. >In C I used to use a memory leak finder that would help me find
  15. >my memory leaks.  I basically created a #define for malloc that redefined
  16. >it ...
  17.  
  18. >I would like to do the same kind of thing in C++.  Unfortunately, it
  19. >seems that new is not as easy to #define over as malloc.  I thought
  20. >(briefly) that I could do something like #define new new(__LINE__,__FILE__) 
  21. > and then overload the new operator, but this causes a recursive macro.
  22.  
  23. There have been two answers to this question that completely missed
  24. the point.  You do NOT want to replace "new" with a macro.  "new" is
  25. a keyword which causes constructors to be called, and memory to be
  26. allocated via the function "operator new()".  If you replace the "new"
  27. keyword with a macro, you destroy the semantics of most programs.
  28.  
  29. You are allowed in C++ to replace "operator new()" and "operator delete()"
  30. with your own versions.  Since these are the functions which actually do
  31. the memory allocation, you can get any effect you want by replacing them.
  32. (If you replace one, you should replace both, to ensure compatibility.)
  33. You don't even have to recompile any code -- just re-link your program.
  34. The ARM and Stroustrup 2 explain how to do this, apart from other books
  35. and many magazine articles which also cover the subject.  It takes a bit
  36. of explaining to cover all the subtle points which you have to consider,
  37. so I prefer not to present just a simplistic answer here.
  38. -- 
  39.  
  40. Steve Clamage, TauMetric Corp, steve@taumet.com
  41. Vice Chair, ANSI C++ Committee, X3J16
  42.