[cairo] cairomm RefPtr

[Murray Cumming]

On Sat, 2007-12-01 at 11:49 -0800, Larry Lewis wrote:
> --- Bertram Felgenhauer <bertram.felgenhauer at googlemail.com> wrote:
> 
> > Larry Lewis wrote:
> > > Is there a specific reason why cairomm's RefPtr implementation
> > (along
> > > with glibmm) does not provide the T_CppObject& operator*() and
> > > T_CppObject* get() methods?  Both reference-counting pointer
> > > implementations I use on a regular basis (boost::shared_ptr and
> > > Poco::SharedPtr) provide this functionality, which is extremely
> > > useful for passing the object by reference or directly accessing
> > > the raw pointer.  It's unfortunate to have to resort to the ugly
> > > operator->() syntax to access the pointer.
> > 
> > Woops sorry, I misread that, apparently you want the C++ object, not
> > the C one. But why would you need the pointer to the C++ object? It
> > only contains is a pointer.
> > 
> > RefPtr is really designed to be used with wrapper objects like these,
> > not for arbitrary C++ objects.
> > 
> 
> I agree that they're not intended for use as general-purpose
> reference-counting pointers. It would be nice, however, to allow
> developers to write API that accepts types such as Cairo::Surface and
> Cairo::Context by reference.

Glib::RefPtr<> and Cairo::RefPtr<> don't make it easy to get a bare
pointer because you might then use it. Then you'd be likely to end up
with a pointer to an object that has been deleted because it's been
completely unreferenced. This would be likely in the situation you
describe.

People would then sometimes do manual reference counting to solve the
problems that they discover, compounding the problem. RefPtr makes life
easy precisely because you should _never_ need to worry about reference
counting.

Even if you were very careful, the existence of operator* would
encourage people to think that they should use it. This is a strategy
that has worked well so far.

>  Using const Cairo::RefPtr<Cairo::Context>

Only of the pointer, though you should use const & to avoid that.

> causes a copy while const Cairo::RefPtr<Cairo::Context>& adds another
> layer of indirection.

I'm not sure what you mean by layer of indirection. No copying or
calling happens when passing a const &.

>  Both force the function writer to perform a NULL
> check, which is contrary to my (and others' I suppose) convention of
> passing by reference to enforce non-NULL parameters.

That's nice sometimes, yes, but it's not the end of the world if you
can't do it.

>  To get a simple
> reference, syntax such as *context.operator->() is required.

-- 
murrayc at murrayc.com
www.murrayc.com
www.openismus.com