[cairo] cairomm: Path destruction

[Rick L Vinyard Jr]

On Sun, 2006-05-07 at 23:20 -0500, Jonathon Jongsma wrote:
> On 5/7/06, Murray Cumming <murrayc at murrayc.com> wrote:
> > > 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.
> 
> That's definitely the simplest solution.  But I have to admit that
> returning a bare pointer to a heap-allocated object leaves a bit of a
> bad taste in my mouth, especially since there are tools available in
> C++ (e.g. smart pointers) to significantly reduce the risk of memory
> leaks in user code.

I suppose that what I find most troubling is that it seems to break from
the style of your other *mm libraries which predominantly use RefPtr's
for heap allocations.

> > > 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.
> 
> That's a good point -- I'd never actually looked into the stability of
> boost libraries before.

While Boost isn't intended to be API stable, I think it's fair to say
that reference counted smart pointers are heading that way:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1450.html

I only know of two places to find the proposed reference implementation;
boost and std::tr1. I would concur that adding a dependency on the
former isn't a good idea. As for the latter, I don't know how widely
available it is outside gcc, if at all.

But, what's wrong with RefPtr? Does it really need a reference function
in the library you're wrapping? I haven't looked into it, but I was
under the impression that it maintained a reference count similar to
std::tr1::shared_ptr, and deallocated when the last reference was
removed.