[cairo] [cairomm] RefPtr<T>::operator*() ?

[Larry Lewis]

----- Original Message ----

> From: Murray Cumming <murrayc at murrayc.com>
> To: Ian Britten <britten at caris.com>
> Cc: cairo at cairographics.org
> Sent: Wednesday, August 20, 2008 10:47:13 AM
> Subject: Re: [cairo] [cairomm] RefPtr<T>::operator*() ?
> 
> On Wed, 2008-08-20 at 11:29 -0300, Ian Britten wrote:
> > Jonathon Jongsma wrote:
> > 
> > >> Just a suggestion, but it might be nice if the cairomm RefPtr
> > >> class had an operator*() (Or, a get(), or something).
> > >>
> > >> Otherwise, if func() is written to accept a "const T &", you
> > >> have to write code like:
> > >>         Cairo::RefPtrsomeObj;  (Populated from somewhere)
> > >>         func( *someObj.operator->() );
> > >> instead of the simpler/cleaner
> > >>         func( *someObj );
> > 
> > > If there is API in cairomm that accepts a 'const T&' where T is supposed 
> > > to be used via RefPtr, it is likely an API bug.  Unfortunately I 
> > > discovered one of these just in the last couple days (the ScaledFont 
> > > constructor) and plan to fix it in a future release.  If you find 
> > > further places where this is the case, please file a bug.
> > 
> > Oops!  Sorry if I wasn't clear...
> > In my example, func() was one of my own functions that I had
> > written (It was actually a template function, but that's irrelevant
> > to this).
> > I didn't mean to imply it was a cairomm function.
> 
> So you should rewrite that function to take a const
> Glib::RefPtr& instead.
> 
> In general we don't have an operator* because people would use it when
> they shouldn't, without knowing that they shouldn't.
> 

You can always dereference it by explicitly calling the -> operator:

  *some_ref_ptr.operator->()

It's a little ugly but it keeps the RefPtr nonsense out of your API.

Larry