Re: Wrapping pangocairo.h

[Murray Cumming <murrayc murrayc com>]

On Tue, 2006-05-30 at 21:16 +0200, Pierre THIERRY wrote:
> Scribit Murray Cumming dies 30/05/2006 hora 18:56:
> > > Why use a helper function (I suppose that it is one) instead of a
> > > constructor? Is it because you want it to return a RefPtr?
> > Yes, all classes that need to be used via RefPtr have no public
> > constructors. They have static create() methods instead.
> 
> Why not have a public constructor to allow it (and thus provide more
> flexibility to the user) along with the helper function that uses
> RefPtr?
> 
> For example, it might be easier for someone using extensively the Boost
> libraries to use boost::intrusive_ptr<T> instead of Glib::RefPtr<T>...

You really need to use RefPtr. Making it possible to not use RefPtr
would not be helpful.

boost::intrusive_ptr<> does look very similar to RefPtr. I've not seen
it before. Maybe it can be used with Glib::Objects's (if it expects
reference() and unreference()), but I can't imagine a big advantage to
using it instead of RefPtr. Certainly no advantage that would outweigh
the problems.

I'm only answering out of politeness. The RefPtr strategy was settled a
long time ago and has been working well enough for a long time. It makes
memory management of these objects vastly more simple and less
vulnerable to errors than people using the C API, for instance.

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