home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18314 < prev    next >
Encoding:
Text File  |  1992-12-22  |  2.0 KB  |  47 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!taumet!steve
  3. From: steve@taumet.com (Steve Clamage)
  4. Subject: Re: Undefined new and delete
  5. Message-ID: <1992Dec22.173713.10373@taumet.com>
  6. Organization: TauMetric Corporation
  7. References: <1992Dec21.162241.12012@cbnewsk.cb.att.com>
  8. Date: Tue, 22 Dec 1992 17:37:13 GMT
  9. Lines: 36
  10.  
  11. swk7@cbnewsk.cb.att.com (steven.w.koenig) writes:
  12.  
  13. >If one wanted to insure that no objects of a given type were ever created
  14. >on the heap, it seems logical that one should be able to declare the
  15. >new and delete operators as private but not define them. cfront 2.1
  16. >only seems to support this if the constructors are inline. The following
  17. >example works if A and ~A are inline, but
  18. [ the linker complains that the new and delete are undefined ]
  19. >if A and ~A are not inline. 
  20.  
  21. Unfortunately, making the new/delete private won't entirely prevent
  22. objects from being constructed on the heap, since
  23.     A *p = new A[10];
  24. will access the global operator new, not the class-specific version.
  25. (In the future, C++ will allow class-specific versions of the array
  26. allocation versions of new and delete.)
  27.  
  28. To address your question, the functions show up as undefined due to a
  29. common constructor/destructor implementation technique.
  30.  
  31. Typically, a flag is passed to the constructor (destructor) to indicate
  32. whether the object needs to be allocated on (returned to) the heap.
  33. The compiler generates code to test the flag and call operator new
  34. (operator delete).  When the constructor/destructor is not inline,
  35. the compiler can't detect that the calls to new/delete are not needed,
  36. so they remain in the code.  (The may have to generate quite a lot
  37. of hidden code in a constructor/destructor, and this is only part of it.)
  38.  
  39. This implementation technique is allowed by the ARM, and I don't
  40. forsee anything in the emerging Standard to disallow it.  You can
  41. define the functions as inline calls to abort() or assert() to get
  42. around the problem.  It defers detection to run time instead of
  43. link time, though.
  44. -- 
  45.  
  46. Steve Clamage, TauMetric Corp, steve@taumet.com
  47.