[cairo] cairomm: Path destruction

[Murray Cumming]

On Sat, 2006-05-06 at 22:52 -0500, Jonathon Jongsma wrote:
> On 5/4/06, Rick L Vinyard Jr <rvinyard at cs.nmsu.edu> wrote:
> > I noticed that Context::copy_path() wraps the call to cairo_copy_path()
> > and allocates an instance of Path on the heap, and ~Path cleans it up by
> > calling cairo_path_destroy().
> >
> > It seems like Context::copy_path() should return a RefPtr<Path>
> > instead...
> 
> I'm not sure that this is true.  RefPtrs are generally used for
> objects that are reference-counted, and I don't think a path is a
> reference-counted object in Cairo.  For instance, there's not a
> cairo_path_reference() function like there is for a context
> (cairo_reference()) or surface (cairo_surface_reference()).
> 
> 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.

>   Which makes it a prime candidate for memory
> leaks, which is definitely not a good thing.  This seems like more of
> a case where you'd want to use a more generic smart pointer type such
> as std::auto_ptr or boost::shared_ptr.  Of course, auto_ptr has
> well-known drawbacks such as the inability to use it with standard
> 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.

> Any other ideas?  Murray, have you had situations like this in any
> other libraries like gtkmm?

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