Re: [gtk-list] bug in object destroy logic?

[Peter Mattis <petm scam XCF Berkeley EDU>]

Raph Levien writes:
>I think there's a bug in the object destroy logic. Consider a hierarchy 
>of objects, A -> B -> C. Let's say that A and C define a destroy method in 
>the class, but B does not. Further, let's say that the destroy methods of 
>A and C follow the idiomatic usage of calling the parent's destroy method 
>at the end.
>
>I think what happens is this: since B did not set a destroy method, the 
>destroy method for A gets copied in. Thus, C's destroy method will call 
>A's (standing in for B's), which in turn will call A's. Thus, A's destroy 
>method ends up getting called twice, which could lead to lots of havoc.
>
>I think the easiest workaround is just to ensure that every object which 
>might get subclassed has an object destroy method defined.
>
>It's also possible I just don't understand the mechanism.

It sounds like you are confusing an object's parent and an object's
parent class. At the end of a destroy method the destroy method for
the objects parent class is called. This is supposed to be exactly
like the way virtual destructors work in C++. 

So if you have a _class_ hierarchy with A derived from B derived from
C and classes A and C define destroy methods the following will happen
when an object of type A is destroyed:

 A's destroy method will be called.
 A's destroy method will call it parent class's destroy method which
   happens to be C's destroy method. (Because A's parent class - B -
   inherits its destroy method from C).
 C's destroy method will run and then attempty to call its parent
   class's destroy method.

The slightly confusing part is that B inherits, it does not copy, the
destroy method from C. Read up on virtual destructor's in C++. That is
the way this mechanism is supposed to work. I attached a really short
C++ example to the end of this message to give an example. Hopefully
the gtk+ code is working the same way. (I think it is, I've purified
gtk+ recently and I'm sure purify would have reported an error for
attempting to free memory twice).

Out of curiosity, did you encounter a bug in this code or is this
something you just stumbled upon and thought it might be a bug?

Peter


-----------------------------------------------------------------


#include <stdio.h>


class C
{
public:
  virtual ~C () { printf ("C::~C\n"); }
};

class B : public C
{
};

class A: public B
{
public:
  virtual ~A () { printf ("A::~A\n"); }
};


int
main ()
{
  A a;
  return 0;
}