[cairo] cairomm: Path destruction

[Jonathon Jongsma]

On 5/8/06, Rick L Vinyard Jr <rvinyard at cs.nmsu.edu> wrote:
> On Sun, 2006-05-07 at 23:20 -0500, Jonathon Jongsma wrote:
> > That's definitely the simplest solution.  But I have to admit that
> > returning a bare pointer to a heap-allocated object leaves a bit of a
> > bad taste in my mouth, especially since there are tools available in
> > C++ (e.g. smart pointers) to significantly reduce the risk of memory
> > leaks in user code.
>
> I suppose that what I find most troubling is that it seems to break from
> the style of your other *mm libraries which predominantly use RefPtr's
> for heap allocations.

I share your concerns about the interface.  For now, I've committed
documentation explaining that the returned Path* needs to be freed,
but I'm personally still hoping to find a better solution...

> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1450.html
>
> I only know of two places to find the proposed reference implementation;
> boost and std::tr1. I would concur that adding a dependency on the
> former isn't a good idea. As for the latter, I don't know how widely
> available it is outside gcc, if at all.

Although I wish we could depend on the new tr1 stuff, I think that's
probably a ways off yet. Has the tr1 stuff even been officially
adopted yet?  I was under the impression that all of the new stuff in
the std::tr1 namespace would get folded into the std namespace when it
was officially accepted.  I haven't been following it too closely
though.

> But, what's wrong with RefPtr? Does it really need a reference function
> in the library you're wrapping? I haven't looked into it, but I was
> under the impression that it maintained a reference count similar to
> std::tr1::shared_ptr, and deallocated when the last reference was
> removed.

RefPtr is an intrusive smart pointer.  In other words, it requires
that any classes used with it have defined reference() and
unreference() member functions.  Generally these functions simply call
the *_reference() or *_unreference() functions for the type that is
being wrapped.  Since it's specifically designed to wrap C types that
keep track of their own reference counts, there's no reference count
internal to the RefPtr class.  If it did keep its own reference count,
you'd be duplicating functionality already in the base type and also
have to worry about keeping the RefPtr reference count synchronized
with the base reference type. This makes it rather sub-optimal as a
general-purpose smart pointer.

Jonner