[cairo] Memory leaks in cairomm

Rodrigo Rivas rodrigorivascosta at gmail.com
Tue Jun 13 06:21:09 PDT 2006


And the reply of Murray forwarded

---------- Forwarded message ----------
From: Murray Cumming <murrayc at murrayc.com>
Date: Jun 13, 2006 11:30 AM
Subject: Re: [cairo] Memory leaks in cairomm
To: Rodrigo Rivas <rodrigorivascosta at gmail.com>
Cc: Murray Cumming <murrayc at murrayc.com>


[snip]
>>HOWEVER, the current system makes it difficult to cast between related
>>types (such as Pattern, or the Surface hierarchy of classes).
>>Cairo::LinearGradient derived = get_some_gradient();
>>Cairo::Gradient base = derived; //Actually, this would work, though it's
>>kind of strange.
>>Cairo::LinearGradient derived2 =
>>dynamic_cast<Cairo::LinearGradient>(base); //Not valid syntax.
>
> Again, I don't see the problem:
>
> Cairo::Gradient base = derived; //Ok, ref. counter incremented

This will cut off any data that's in derived but not in the base, though
we don't have anything like that now. If I derive my own type and do that
then it will be a problem.

> Cairo::LinearGradient linear = base ; //Ok, ref. counter incremented
>
> You don't need casts, operator=() makes the needed steps, that is,
> increment the counter. Sure, you can't be sure if base is actually a
> LinearGradient, but that's because cairo doesn't tell you that.

a) I think cairo can now. There's new API.
b) A dynamic_cast<> would use the C++ type information.

> Besides, the subclasses of gradient, for instance, are most useful for
> constructors, as they have few new functions, so the "downcast" is not
> really very useful.
>
>>There's also the issue of constness. A const smartpointer can act like a
>>const pointer, and prevent an implicit cast to a non-const smartpointer.
>
> I don't think the const is a problem with the ref-semantic solution.

I don't understand. Const is useful and C++ coders like it. Note that the
refcount in smartpointers is generally mutable, so that you can refcount
const pointers.

> IMHO, if cairo manages memory and the lifetime of its objects (with
> reference counting) is it far better to leave it this way and not to
> duplicate the effort and the work to build another layer of
> indirection/managemet over it.
>
> Remember the KISS principle.

Sure, the lack of reference-counting of the C++ wrapper would maybe be a
plus for the implementation. But I still think it makes the API awkward,
for the reasons stated.

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


More information about the cairo mailing list