Re: RFC: Reference counts on Gtk2::Tooltips
- From: Andrew Pimlott <gtk-perl-list andrew pimlott net>
- To: gtk-perl-list gnome org
- Subject: Re: RFC: Reference counts on Gtk2::Tooltips
- Date: Mon, 5 May 2003 15:08:12 -0400
On Mon, May 05, 2003 at 11:40:31AM -0400, muppet wrote:
this happens because although the tooltips object stores a pointer to itself
in the client widget's user data, it does not allow that pointer to keep a
reference. thus, it is up to the application programmer to store a reference
to the tooltips object which will outlive the objects which have the tooltips
attached to them.
Is there any chance of fixing gtk?
in other words, it behaves as designed.
however, that behavior is rather surprising. also, from what i can tell it is
unexpected, since most C code i've seen actually leaks the tooltips objects so
they stay alive by accident.
So if you preserve the C behavior in Perl, how could the Perl
programmer avoid leaking tooltips? Basically, you're saying that
every Perl programmer that doesn't want a memory leak has to invent
his own way of managing tooltips. That seems like a pointless waste
it is trivial to have the perl wrapper for set_tip keep a reference on the
tooltips object so that it will stay alive; my question is, since it's
behaving as designed, is this subversion the right thing to do? or should we
simply document the behavior in a "pitfalls" or "gotchas" document?
Does the C API have the hooks you would need to dereference the
tooltips when the widget is destroyed? If so, why not fix it?
People expecting the C behavior would lose nothing, and people
expecting sane semantics would not be surprised.
In general, documenting pitfalls is stupid. Even in the unlikely
case that a programmer reads it, every pitfall is something else he
has to keep in mind. If the problem is recognized, fix it.
] [Thread Prev