[gst-devel] Why do we call gst_object_unref() ?

[Gruenke, Matt]

Agreed about the point of always checking the docs.  It occurred to me
that I should have mentioned this.  Not only must you always check
whether the caller is responsible for unreffing an object returned by a
function, but note that some functions cause ownership or refcount
transfer of objects passed as parameters.  Therefore, don't forget to
check what the docs say about each parameter, in addition to the return
types.

Over time, you'll start to notice some patterns.  For instance, macros -
which are in ALL_CAPS - tend not to affect refcounts or ownership.


BTW, parenting is only valid for objects derived from GObject.  There's
another baseclass in use, called GstMiniObject.  These are used for
lighter-weight objects where refcounting is still desirable, like
buffers.  Not only can these not be parented (or weak ref'd), but they
also must be unref'd using a function specific to that type (e.g.
gst_buffer_unref()), rather than gst_object_unref().


Matt


-----Original Message-----
From: Wes Miller [mailto:wmiller at sdr.com] 
Sent: Monday, January 03, 2011 13:40
To: gstreamer-devel at lists.sourceforge.net
Subject: Re: [gst-devel] Why do we call gst_object_unref() ?


<snip/>

This can be messy and confusing.  Be sure to read the description of
every
g_ and gst_ call you make to see if it tells you to unref something.

<snip>