[cairo] Memory leaks in cairomm

[Jonathon Jongsma]

On 6/12/06, Rodrigo Rivas <rodrigorivascosta at gmail.com> wrote:
> I don't know if I'm missing something, but I've noted that the RefPtr
> implementation in cairomm leaks memory "always".
> That is because when you call, say Surface::create(...), it calls
> basically "new Surface(cairo_surface_create_linear(...))" and returns
> the new pointer wrapped into a RefPtr<Surface>. The ~RefPtr decrements
> the ref-counter of the cairo_surface_t object, but it <never> deletes
> the new'ed Surface object. It's same for every type in cairomm.

wow.  yeah, that's a problem.

> The glibmm's RefPtr doesn't leak! But that's because the
> Glib::ObjectBase class takes care of this, and gets notified when the
> wrapped object is destroyed.
> Also there are a few Glib classes that doesn't inherit from
> Glib::ObjectBase, such as Glib::Thread. Those are implemented simple
> as cast pointers to the underlying type (I'm not sure this is 100%
> portable, valid C++ code, but it will probably work as long as there
> is no virtual functions and no member variables).

This scares me a little bit.  It seems to be pretty limiting since it
basically precludes us from ever using a virtual function in the
future.

It would be helpful if there were a way of determining whether the
reference count of the underlying object has reached zero and is
destroyed.  For a cairo_t, destroying the object doesn't set the cr
pointer to NULL.  Does anybody know whether there is any other way of
determining whether an underlying object has been destroyed?

Thanks,
Jonner