[cairo] cairomm: Path destruction

Rick L Vinyard Jr rvinyard at cs.nmsu.edu
Mon May 8 21:09:31 PDT 2006

On Sun, 2006-05-07 at 23:20 -0500, Jonathon Jongsma wrote:
> On 5/7/06, Murray Cumming <murrayc at murrayc.com> wrote:
> > > On the other hand, the semantics of the current interface don't really
> > > give you any clue that you need to delete the Path* that's returned by
> > > Context::copy_path() (outside of API documentation which doesn't exist
> > > yet for these functions).
> >
> > So let's just document it.
> 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.

> > > containers.  And I'd prefer not to add too many extra dependencies to
> > > cairomm that don't exist for standard cairo (although boost is
> > > probably one of the more acceptable dependencies since it's
> > > practically a standard library extension)...
> >
> > It's not API stable, and doesn't intend to be.
> That's a good point -- I'd never actually looked into the stability of
> boost libraries before.

While Boost isn't intended to be API stable, I think it's fair to say
that reference counted smart pointers are heading that way:


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.

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

More information about the cairo mailing list