[gst-devel] explicit g_object_dispose on anything?

Mathrick mnews2 at wp.pl
Sat Feb 7 14:58:15 CET 2004


W liście z pią, 06-02-2004, godz. 12:52, Benjamin Otte pisze: 
> On Fri, 6 Feb 2004, Mathrick wrote:
> 
> > > Maybe we need to do s/dispose/finalize/ everywhere?
> >
> > No. You cannot safely replace dispose with finalize. In fact, you
> > should't even consider them in terms of alternatives, they're
> > complementary and supposed to be (eventually) called in order.
> >
> For C code it seems to be completely uninteresting which fnction to use.

Yes, for C code it's indifferent. But it wasn't C they got added for in
the first place. And if we want to stay bindings-clean, we should behave
nice and follow the rules. Plus, I don't think you can omit any of the
two for properly written GObject code and still expect it to work
correctly, ie. even in C you must call _dispose and then _finalize.

> > > I'm not even sure what the difference between dispose and finalize is.
> >
> > It's kinda substantial, although not obvious and for many uses it may go
> > unnoticed.
> >
> > > Anyone knows?
> >
> > Yep. http://www.le-hacker.org/papers/gobject/ch04s02.html ;)
> >
> That still doesn't tell me what i"m supposed to do where. What memory am I
> supposed to release in _dispose, what memory do I release in _finalize?

For me it seems pretty clear. After _dispose, you are supposed to not
hold any external refs, but still be able to invoke methods without
SEGV. After _finalize, every resource you allocated should be freed.
AFAICT, it's up to you to decide what mem free when, provided you
conform to the rules above.

> I guess we should leave that to the bindings writers who can figure it out
> themselves. They're the ones invoking _dispose directly ;)

As long as we don't step on bindings toes by invalid usage of said
functions, it's perfectly fine to leave to them hard work of deciding
;).

-- 
"Tautologizm to coś tautologicznego"
   Maciej Katafiasz <mnews2 at wp.pl>
       http://mathrick.blog.pl





More information about the gstreamer-devel mailing list