[cairo] cairomm: Path destruction

[Rick L Vinyard Jr]

On Mon, 2006-05-08 at 23:47 -0500, Jonathon Jongsma wrote:
> Although I wish we could depend on the new tr1 stuff, I think that's
> probably a ways off yet. Has the tr1 stuff even been officially
> adopted yet?  

AFAIK there have only been two proposed alternatives to shared_ptr as
implemented in std::tr1.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1739.pdf

and

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1851.pdf

I think it is fair to (roughly) summarize both proposals as
std::tr1::shared_ptr + something else.

> I was under the impression that all of the new stuff in
> the std::tr1 namespace would get folded into the std namespace when it
> was officially accepted.  

It will be... at least those portions that are adopted. I also think
that it's fair to say that there is sufficient dissatisfaction with
std::auto_ptr that some form of replacement is imminent. Well, imminent
on the time scale of standards committees at least... sort of like an
entish debate.

Something else to consider if you decided to go down the
std::tr1::shared_ptr route; like refptr.h, the header boost_shared_ptr.h
could be included in cairomm instead of relying on std::tr1 to have it
available or adding a dependency on boost.

> > But, what's wrong with RefPtr?
> 
> it's specifically designed to wrap C types that
> keep track of their own reference counts, there's no reference count
> internal to the RefPtr class.

Ahhh, I remembered there was something about it that was tuned to
wrapping Gtk and different from a general purpose smart pointer. That
jogs the memory now. Thanks.