A New Krazy Checker for Methods Returning const refs

[Jos van den Oever]

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.

> > 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?

I agree with the general idea. kdelibs contains highlevel libraries
and as such the API should be easy and relatively foolproof as well as
easy to generate bindings for. It's just that i rather like using
things like:

const X& x = y.x();
playWithX(x);

And this often makes sense.
I also do not see the clear distinction between return values and
function arguments. Nothing stops a class from storing a pointer or
reference to an argument that is passed to one of its member
functions. Should we change the API to make this impossible too?

Cheers,
Jos