[618] in The GTK GIMP ToolKit mailing list archive
[gtk-list] Re: bug in object destroy logic?
daemon@ATHENA.MIT.EDU (Peter Mattis)
Fri Aug 1 15:39:58 1997
To: gtk-list@redhat.com
In-reply-to: Your message of "Fri, 01 Aug 1997 11:16:24 PDT."
<Pine.BSF.3.91.970801111135.21585A-100000@blacklodge.c2.net>
Date: Fri, 01 Aug 1997 12:30:43 -0700
From: Peter Mattis <petm@scam.XCF.Berkeley.EDU>
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
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;
}
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
