From: soloway@midniteoil.Eng.Sun.COM (Mark Soloway)
Newsgroups: alt.toolkits.xview
Subject: Re: UIT with g++ ?
Date: 21 Jan 1993 23:33:11 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: uit-hotline@midniteoil.Eng.Sun.COM
NNTP-Posting-Host: midniteoil

In article llu2ubINNeqm@appserv.Eng.Sun.COM, soloway@midniteoil.Eng.Sun.COM (Mark Soloway) writes:
In article Ht9@boulder.parcplace.com, imp@boulder.parcplace.com (Warner Losh) writes:
>In article <lmfken.727445392@bluese2> lmfken@lmf.ericsson.se (Kenneth
>Osterberg) writes: 
>>Perhaps some c++ guru could comment on the validity of the
>>messages, is there a danger with having a nonvirtual
>>destructor in a class with virtual functions?
>
>When you have a class that has virtual member functions, that class
>will tend to be subclassed.  When you subclass, those destructors
>(dtor) won't be called when you delete a subclassed object.  If the
>dtors are virtual, then the subclass's dtor will get called, then its
>parent's dtor, all the way back to the root object.
>
>For example:
>class A {
> public:
>	~A();
>	virtual void foo();
>}
>class B : public A {
> public:
>	~B();
>}
>
>when I delete an object of type B, then ~B will be called.  If the
>destructor in A was virtual, then ~B and ~A would get called.  When
>you subclass, that is almost always what you want to have happen,
>so that each subclass knows just enough to tear down their object and
>then let its parent class do the rest.

This is not quite technically accurate.  In fact, if you create the
following code:

	B *b = new b;
	delete b;

Both the B and the A destructors are called in that order regardless of
whether or not the destructor is virtual or not.  Where the virtual destructor
comes into play is when you are using polymorphism:

	A *b_in_A_ptr = new B;
	delete b_in_A_ptr;

In this case the pointer to an instance of B is contained by a pointer
to its base class A.  Without a virtual destructor C++ will not know that
it is really a B object and it will only call A's destructor.  If the destructor
for class A is virtual, then the subclass destructors and the base class destructor
is called (in this case the B and A destructors in that order).

The general rule of thumb is that if there are virtual functions then the interface
implies that polymorphism is expected and that a pointer to a subclass may be
contained in a pointer to a higher level (towards the base) class.  Therefore,
you should probably have a virtual destructor in case someone tries to delete
the pointer.

>I don't know UIT at all, so I can't tell you if it is doing the right
>thing or not.

Most of the time UIT users instantiate UIT objects as automatic variables
(on the stack, not on the heap).  In that case the destructors are definitely
being called correctly.  In the case where someone is "new"-ing the objects
onto the heap, most UIT users are placing the pointer in a pointer to the
appropriate subclass and are deleting that pointer, so the destructors are
being called correctly.

In the few cases where people are using polymorphism with the UIT and deleting
pointers to UIObjects or some higher level class then the actual object created,
the destructors are not being called properly in some versions of the UIT.
UIT V3 changes the Generic destructor to be virtual and has a multitude of internal
bug fixes that makes sure that XView objects underneath the wrappers are destroyed
in a way that won't hurt any other UIT objects.  If you have UIT V2, you can
change the destructor in the Generic class to be virtual, but there are some
cases where it may cause detrimental effects if you are allocating objects on
the heap and you do not destroy them in the right way.

Like I mentioned above, in general the lack of a virtual destructor is not
hurting most UIT users.  If you do have a case where it is really affecting you,
try changing the Generic class.  If that causes more problems, then contact the
uit-hotline (uit-hotline@midniteoil.Eng.Sun.COM) and we can work it out...

							- Mark
__________________________________________
\_Mark Soloway (mark.soloway@Eng.Sun.COM)_\
/_Distributed Systems Services (ToolTalk)_/
\__SunSoft (A Sun Microsystems Company)___\