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

[Ian Britten]

Murray Cumming 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::RefPtr<T> someObj;  (Populated from somewhere)
>>>>         func( *someObj.operator->() );
>>>> instead of the simpler/cleaner
>>>>         func( *someObj );

> So you should rewrite that function to take a const
> Glib::RefPtr<SomeCairoThing>& instead.

I guess we'll have to disagree about this.

It would be bad coupling for func() to know/care about how T was
allocated (heap, stack, RefPtr, etc).  It just wants to work with
a (non-NULL) reference to the object.

Putting a RefPtr on the parameter of func() simply introduces
more work, since:
- If the memory management ever changes (eg: boost::shared_ptr),
   then the API of func() would need to be changed needlessly.
- func() now has to check for, and address, the possibility of
   NULL (ie: An empty RefPtr) being passed in.
Both of these things are only of concern to the caller of func(),
not to the implementation of func().

> In general we don't have an operator* because people would use it when
> they shouldn't, without knowing that they shouldn't.

Well, all the other smart/auto pointers (std, boost, etc) have
them, so I'd politely suggest that most people consider their
presence more beneficial than the risk they could introduce.
(Besides, if someone doesn't know C++ well, there's thousands of
ways they can get into trouble).

Anyway, just my $0.02  :)
Ian