[cairo] cairomm RefPtr

[Larry Lewis]

--- Murray Cumming <murrayc at murrayc.com> wrote:

> 
> 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.
> 

I understand this may cause unintended behavior if you don't really
understand the shared pointer concept. I will accept passing const
RefPtr references around for the sake of the uninformed programmer.

> >  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 &.

What's really going on here is passing a pointer (the reference) to a
pointer (the pointer within RefPtr).

> 
> >  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
> 
> 

Thanks for the replies. I'll defer this discussion until TR1 is
approved and the C++ library gets a proper shared pointer
implementation.

Larry