home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13308 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  2.6 KB

  1. Path: sparky!uunet!van-bc!rsoft!agate!stanford.edu!ames!sun-barr!cs.utexas.edu!ut-emx!jamshid
  2. From: jamshid@ut-emx.uucp (Jamshid Afshar)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Explicit Calls to Destructors (SunCC=ok, gcc=not)
  5. Summary: use "this->~T()" ("this->T::~T() to workaround gcc bug)
  6. Keywords: destructors
  7. Message-ID: <79121@ut-emx.uucp>
  8. Date: 4 Sep 92 19:31:23 GMT
  9. References: <gnusenet2234@h.cs.wvu.wvnet.edu>
  10. Reply-To: jamshid@emx.utexas.edu
  11. Organization: The University of Texas at Austin; Austin, Texas
  12. Lines: 61
  13.  
  14. In article <gnusenet2234@h.cs.wvu.wvnet.edu> schiebel@cs.wvu.wvnet.edu (Darrell Schiebel) writes:
  15. >    In the Sun (SC1.0 w/ cfront 2.1 (I think)), an explicit call
  16. >    to a class' destructor from within a one of the class' member
  17. >    functions works:
  18. >
  19. >    void Tess::cleanup(Bool abort) {
  20. >      Tess::~Tess();
  21. >        }
  22.  
  23. That's not the correct way to call a dtor.  It probably doesn't work
  24. under later versions of cfront.
  25.  
  26. >    However, in gcc-2.2.2 this does not work ...
  27. >
  28. >    Other nonworking variations:
  29. >
  30. >    this->~Tess();            AND
  31. >    (*this).~Tess();        WITH THE ERROR MESSAGE: ...
  32.  
  33. Both of these are correct -- you've encountered a gcc-2.2.2 bug.
  34. Btw, it is also legal (since the ARM) to explicitly destroy built-in
  35. types (it's a no-op, of course).  This makes it easier to instantiate
  36. templates which explicitly destroy their objects with built-in types.
  37. Note, BC++ 3.0 didn't implement this feature, and BC++ 3.1 only allows
  38. one form of the syntax:
  39.  
  40.     int i;
  41.     int* p = &i;
  42.     i.~int();  // correct, but BC++ error
  43.     p->~int();  // correct, but BC++ error
  44.     i.int::~int();  // correct, but BC++ error
  45.     p->int::~int();  // correct and BC++ allows
  46.  
  47. The difference between:
  48.     p->~T();
  49. and
  50.     p->T::~T();
  51. is that the second overrides the "virtualness" of the dtor (if it is
  52. virtual).  You should therefore almost always use the first form.  Besides,
  53. it's less characters and not any slower if ~T() isn't virtual.
  54.  
  55. >    and finally:
  56. >
  57. >    ~Tess();            WITH:
  58.  
  59. You must explicitly use a "." or "->" whenever calling the dtor, even
  60. from within a member function.  'this' is not assumed.  The above
  61. tries to create a temporary Tess and call it's unary ~ operator (see
  62. ARM 12.4).
  63.  
  64. >    Is there some way to get around this in gcc? Its exactly what
  65. >    I want to do; I don't want to force users of my class to call
  66. >    parent ``cleanup'' functions, in children. Explicit calls to
  67. >    destructors is permitted, ARM p.278, sec 12.4.
  68.  
  69. I think someone said "this->Tess::~Tess()" works under gcc.  Just
  70. remember that this will not call the destructor of derived class
  71. (I'm assuming ~Tess() is declared virtual).
  72.  
  73. Jamshid Afshar
  74. jamshid@emx.utexas.edu
  75.