[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() );
}
};
protected:
cairo_path_t* cobject;
};
std::tr1::shared_ptr<Path> Context::copy_path() const
{
cairo_path_t* cresult =
cairo_copy_path(const_cast<cairo_t*>(m_cobject));
check_object_status_and_throw_exception(*this);
std::tr1::shared_ptr<Path> path(new Path(cresult),
Path::cairo_path_deleter()
);
return path;
}
More information about the cairo
mailing list