[cairo] Memory leaks in cairomm

[Rodrigo Rivas]

Ooops! Looks like I am pissed with the mail, and got the reply wrong!
Here is the reply:

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


> [snip]
>
> Apart from my general wish to make it more obvious that these types behave
> in this way, here was where I made the choice, and why:
> http://lists.freedesktop.org/archives/cairo/2005-December/005877.html
>
> As in all choices, there's advantages and disadvantages.

Yeah, I've read these... but I'm afraid I disagree...

>This will surprise some people who expect all copy constructors to do
>copy-by-value, but it's not so unusual, and I'm afraid that people will
>find smartpointer syntax ugly:

You can just rename the classes to something like ContextRef or
ContextPtr, instead of just Context, but I see that rather
unnecessary. Anyway, people shouldn't expect anything, they should
read the docs! And reference semantics is not unknown to the C or C++
programmers, handles, sockets, pointers, etc. behave this way.

>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
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.
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.

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.
--
Rodrigo.