[cairo] cairomm: Path destruction

[Jonathon Jongsma]

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

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

Jonner