[Development] QString behavior change

[Thiago Macieira]

On Tuesday 11 August 2015 19:09:22 Allan Sandfeld Jensen wrote:
> I would second that. We can argue that the null vs empty is a misfeature we 
> like to discourage because it is likely to break in some corner-cases, but
> until we get rid of it (Qt6), there is no reason to not try to be
> consistent, and deal properly with the differences when bugs are reported.

Actually, looking at the code, I was worried about the wrong part. As pasted:

        if (begin == str.cbegin() && end == str.cend())
            return str;
        if (begin == end)
            return StringType();

If the string is already empty, the first line will match. That's also the only 
case when a null string would come in. So we can be sure that the next one is 
non-null and could return StringType("").

I won't do that because of the next two lines:

        if (!isConst && str.isDetached())
            return trimmed_helper_inplace(str, begin, end);

This is what makes the rvalue-ref QString::trimmed() not allocate memory. In 
fact, I think the if (begin == end) conditional is unnecessary. Just remove 
those two lines.

I won't do this change, but I will accept a patch from someone who does. I 
will accept it only because it's a performance improvement, not because it 
keeps the nullness.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center