[cairo] cairomm: Path destruction

[Murray Cumming]

On Tue, 2006-05-09 at 10:19 -0400, Owen Taylor wrote:
> On Thu, 2006-05-04 at 19:54 -0600, Rick L Vinyard Jr 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...
> 
> Speaking on a theoretical level, and not making recommendations for
> cairomm directly:
> 
> Since cairo_path_t is an immutable type, it doesn't really make sense
> to me to pas it around as a pointer at all in C++; the caller can't
> care about identity, so you might as well return a bare Path which
> is *internally* a smart pointer, but doesn't reveal that to the 
> programmer.

This sounds sensible.

It could get complicated if we start to use a Cairo::Path to wrap a
cairo_path_* that we get from cairo. For instance, if there was a 
cairo_path_t* cairo_something_get_path_foo(cairo_something_t* context)
function, because cairo would not give us ownership of the object, and
we'd have no way to copy it. So the application code could end up with a
Cairo::Path that had an invalid underlying cairo_path* instance.

But we don't need to do that at the moment, I think.

> This probably would mean using a two-part object ... having an internal
> object that is reference counted and memory manages the cairo object
> and a public object that is a smart pointer to that.
> 
> (You could probably just get away with copying the cairo_path_t in
> a copy constructor and only have a one-part object... compilers are
> smart these days... but it's very clunky to copy a cairo_path_t so
> it wouldn't be noticeably easier.)

This would be preferable, if we could implement cairo_path_copy().

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