[cairo] cairomm: Path destruction

Rick L Vinyard Jr rvinyard at cs.nmsu.edu
Tue May 9 21:41:36 PDT 2006

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

Along those lines, I wonder about using a custom deleter like:

class Path {

  inline cairo_path_t* cobj() { return m_cobject; }

  struct cairo_path_deleter {
    void operator()(Path* p) const {
      if (p)
        cairo_path_destroy( p->cobj() );

    cairo_path_t* cobject;


std::tr1::shared_ptr<Path> Context::copy_path() const
  cairo_path_t* cresult =  


  std::tr1::shared_ptr<Path> path(new Path(cresult),

  return path;

More information about the cairo mailing list