home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / cplus / 1978 < prev    next >
Encoding:
Text File  |  1993-01-06  |  1.9 KB  |  51 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!max.fiu.edu!serss0!feathers
  3. From: feathers@serss0 (Michael Feathers)
  4. Subject: Re: Overloading operator delete
  5. Organization: Florida International University, Miami
  6. Date: Wed, 6 Jan 1993 12:12:54 GMT
  7. Message-ID: <C0FLxJ.L25@fiu.edu>
  8. References: <C0Ex9D.Ct7@fiu.edu>
  9. Sender: news@fiu.edu (Usenet Administrator)
  10. Lines: 39
  11.  
  12. I am the author of this article.  I just realized that I did not explain 
  13. thoroughly.  
  14.  
  15. In article <C0Ex9D.Ct7@fiu.edu> feathers@serss0 (Michael Feathers) writes:
  16. >
  17. >I discovered the hard way a while ago that the operator delete can not be
  18. >overloaded in C++.
  19.  
  20. That is, overload operator delete with the placement syntax.  We can provide
  21. extra versions of operator new with an arbitrary number of additional 
  22. arguments, but there can be no additional arguments to delete other than 
  23. those specified in the ARM.
  24.  
  25. I don't have the ARM at home with me right now, so I can not recite chapter
  26. and verse.
  27.  
  28. >I've read the annotation in the ARM and I can not say that I agree with
  29. >the reasoning.  One example given for overloading operator new involves using 
  30. >another arena for allocation.  But how will this memory be deallocated? 
  31. >
  32. >Doesn't the possibility of using the global delete accidently make the 
  33. >absence of an overloadable delete at least as "hazardous" as allowing it?
  34. >
  35. >I understand that there are many applications in which programmers may not
  36. >be concerned with reclaiming memory, but aren't there enough to justify being
  37. >able to use operator delete symmetrically with operator new without resorting
  38. >to the work around discussed in the ARM?
  39. >
  40. >The work around that I've choosen involves using a set of malloc/free type
  41. >functions since I have no means of using an overloaded delete symmetrically 
  42. >with an overloaded new.
  43. >
  44. >Michael Feathers   [feathers@fiu.edu]
  45. >
  46. >
  47.  
  48. Michael Feathers [feathers@fiu.edu]
  49.  
  50.  
  51.