[cairo] Memory leaks in cairomm

[Murray Cumming]

> On 6/12/06, Rodrigo Rivas <rodrigorivascosta at gmail.com> wrote:
[snip]
>>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.

Well spotted. It's much better to know about this now than after we've
frozen the API/ABI.

By the way, the only reason that we'd want the C++ wrapper object to live
longer than any of our RefPtrs to it is in case the underlying C object
(that may continue to be used by the underlying C Cairo library) is
delegating something to the wrapper.

In gtkmm, that means default signal handlers and other virtual function
overrides. But I don't think there's anything like that in cairo yet. I
don't think there's even any callbacks, which C++ would wrap to virtual
methods.

So maybe we could decide to delete our C++ wrapper as soon as the last
RefPtr is gone. We could use a second refcount, or maybe this version of
the RefPtr would be useful. It only references the C object once, and then
acts like a non-intrusive sharedptr. I was never brave enough to risk
replacing Glib::RefPtr with it for gtkmm:
http://bugzilla.gnome.org/show_bug.cgi?id=104332

I also need to get around to adding a sharedptr for the implementation of
Path:
http://lists.freedesktop.org/archives/cairo/2006-May/006907.html
Maybe that's something we could reuse.

Murray Cumming
murrayc at murrayc.com
www.murrayc.com
www.openismus.com