A New Krazy Checker for Methods Returning const refs

[Thomas Zander]

On Sunday 15 April 2007 20:12, Jos van den Oever wrote:
> 2007/4/15, Kevin Ottens <ervin at kde.org>:
> > > Yes, that's bad design but not on the part of your class.
> > > If every class is forced to only give out threadsave implicitly
> > > shared objects, you might as well use java.
> >
> > Actually that's wrong, you don't have implicitely shared objects in
> > java. You manipulate pointers all the time and it's far from being
> > threadsafe if you don't use them with extra care.
>
> A java.lang.Object is nothing but a wrapper around a pointer.
> QSharedDataPointer has copy-on-write which is different from what java
> does.

I think the proper way to look at Java is that you _only_ return and 
manipulate pointers. A trick that can only be useful in a language that 
has garbage collection ;)
But, yeah, your point is correct.

> > > It means that using any STL class
> > > is out of the question unless it is wrapped. That's a silly
> > > overhead.
> >
> > Using STL in kdelibs public API looks like masochism anyway. :-)
>
> So what about returning pointers?

My policy is that returnng pointers is only allowed in two cases;
a) when transferring ownership of the object.  Factory methods come to 
mind.
b) when the class returning the pointer didn't have ownership anyway. 
Think manager design pattern

Unfortunately it is required to have a set of rules like this to avoid 
memory leaks or worse.
-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070415/c42ea55f/attachment.sig>