[cairo] [cairomm] RefPtr<T>::operator*() ?
britten at caris.com
Wed Aug 20 08:41:58 PDT 2008
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 :)
More information about the cairo