[cairo] [cairomm] RefPtr<T>::operator*() ?
lewislp at yahoo.com
Wed Aug 20 08:16:51 PDT 2008
----- 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:
It's a little ugly but it keeps the RefPtr nonsense out of your API.
More information about the cairo