home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / windows / openloo / 5116 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  4.3 KB

  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!news2me.EBay.Sun.COM!exodus.Eng.Sun.COM!appserv.Eng.Sun.COM!midniteoil!soloway
  2. From: soloway@midniteoil.Eng.Sun.COM (Mark Soloway)
  3. Newsgroups: comp.windows.open-look
  4. Subject: Re: UIT with g++ ?
  5. Date: 21 Jan 1993 20:47:07 GMT
  6. Organization: Sun Microsystems, Inc.
  7. Lines: 86
  8. Distribution: world
  9. Message-ID: <llu2ubINNeqm@appserv.Eng.Sun.COM>
  10. References: <C15xoG.Ht9@boulder.parcplace.com>
  11. Reply-To: uit-hotline@midniteoil.Eng.Sun.COM
  12. NNTP-Posting-Host: midniteoil
  13.  
  14. In article Ht9@boulder.parcplace.com, imp@boulder.parcplace.com (Warner Losh) writes:
  15. >In article <lmfken.727445392@bluese2> lmfken@lmf.ericsson.se (Kenneth
  16. >Osterberg) writes: 
  17. >>Perhaps some c++ guru could comment on the validity of the
  18. >>messages, is there a danger with having a nonvirtual
  19. >>destructor in a class with virtual functions?
  20. >
  21. >When you have a class that has virtual member functions, that class
  22. >will tend to be subclassed.  When you subclass, those destructors
  23. >(dtor) won't be called when you delete a subclassed object.  If the
  24. >dtors are virtual, then the subclass's dtor will get called, then its
  25. >parent's dtor, all the way back to the root object.
  26. >
  27. >For example:
  28. >class A {
  29. > public:
  30. >    ~A();
  31. >    virtual void foo();
  32. >}
  33. >class B : public A {
  34. > public:
  35. >    ~B();
  36. >}
  37. >
  38. >when I delete an object of type B, then ~B will be called.  If the
  39. >destructor in A was virtual, then ~B and ~A would get called.  When
  40. >you subclass, that is almost always what you want to have happen,
  41. >so that each subclass knows just enough to tear down their object and
  42. >then let its parent class do the rest.
  43.  
  44. This is not quite technically accurate.  In fact, if you create the
  45. following code:
  46.  
  47.     B *b = new b;
  48.     delete b;
  49.  
  50. Both the B and the A destructors are called in that order regardless of
  51. whether or not the destructor is virtual or not.  Where the virtual destructor
  52. comes into play is when you are using polymorphism:
  53.  
  54.     A *b_in_A_ptr = new B;
  55.     delete b_in_A_ptr;
  56.  
  57. In this case the pointer to an instance of B is contained by a pointer
  58. to its base class A.  Without a virtual destructor C++ will not know that
  59. it is really a B object and it will only call A's destructor.  If the destructor
  60. for class A is virtual, then the subclass destructors and the base class destructor
  61. is called (in this case the B and A destructors in that order).
  62.  
  63. The general rule of thumb is that if there are virtual functions then the interface
  64. implies that polymorphism is expected and that a pointer to a subclass may be
  65. contained in a pointer to a higher level (towards the base) class.  Therefore,
  66. you should probably have a virtual destructor in case someone tries to delete
  67. the pointer.
  68.  
  69. >I don't know UIT at all, so I can't tell you if it is doing the right
  70. >thing or not.
  71.  
  72. Most of the time UIT users instantiate UIT objects as automatic variables
  73. (on the stack, not on the heap).  In that case the destructors are definitely
  74. being called correctly.  In the case where someone is "new"-ing the objects
  75. onto the heap, most UIT users are placing the pointer in a pointer to the
  76. appropriate subclass and are deleting that pointer, so the destructors are
  77. being called correctly.
  78.  
  79. In the few cases where people are using polymorphism with the UIT and deleting
  80. pointers to UIObjects or some higher level class then the actual object created,
  81. the destructors are not being called properly in some versions of the UIT.
  82. UIT V3 changes the Generic destructor to be virtual and has a multitude of internal
  83. bug fixes that makes sure that XView objects underneath the wrappers are destroyed
  84. in a way that won't hurt any other UIT objects.  If you have UIT V2, you can
  85. change the destructor in the Generic class to be virtual, but there are some
  86. cases where it may cause detrimental effects if you are allocating objects on
  87. the heap and you do not destroy them in the right way.
  88.  
  89. Like I mentioned above, in general the lack of a virtual destructor is not
  90. hurting most UIT users.  If you do have a case where it is really affecting you,
  91. try changing the Generic class.  If that causes more problems, then contact the
  92. uit-hotline (uit-hotline@midniteoil.Eng.Sun.COM) and we can work it out...
  93.  
  94.                             - Mark
  95. __________________________________________
  96. \_Mark Soloway (mark.soloway@Eng.Sun.COM)_\
  97. /_Distributed Systems Services (ToolTalk)_/
  98. \__SunSoft (A Sun Microsystems Company)___\
  99.  
  100.