A New Krazy Checker for Methods Returning const refs

[Thiago Macieira]

Simon Hausmann wrote:
> On Monday 16 April 2007 10:20:58 Mirko Boehm wrote:
[snip]
>> I oppose this policy. It makes writing classes harder, since we have to
>> continuously distinguish between standard library classes and our own.
>> And
>> I have a hard time seeing the benefits.
>
[snip]
> library in the future without breaking compatibility outweights the ease
> of
> writing the library code.

I would argue that it's easier to write library code that returns values
instead of const-refs: there are less constraints on code, not less.

For instance, the following isn't valid:

const QStringList &Foo::bar() const
{
    return d->data.split(QLatin1Char(':'));
}

And it wouldn't be either even with std::list<T>.

Next, our public API doesn't use STL classes. Most if not all classes we
use in the kdelibs public API are implicitly shared. Any that isn't could
be analysed and made so, if needed be (maybe they're too small to warrant
the hassle of a QAtomic).

Anyways, if a developer clearly needs to break the rule because the API
and/or implementation would be better returning a const-ref, I don't see
why he couldn't. There are exceptions to every rule. He should only
clearly understand the issues.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358