[Development] QList

[Thiago Macieira]

On segunda-feira, 27 de março de 2017 00:59:58 PDT Lars Knoll wrote:
> I am with Marc here. I don’t really see any advantage of inheriting QString
> from QStringView. Rather I think it’ll confuse people, even if the
> inheritance is private.

I guess I will just have to prove that:
 a) code generation will be better
 b) maintenance will be lower
 c) people will not be confused (because they won't know)

> The pattern I currently think would be best is the following:
> 
> Make QString and QStringView two independent classes. Share most of the
> implementation, by either making the const methods in QString call the
> methods in QStringView (as in QString::indexOf(…) { return
> QStringView(*this).indexOf(…); }) or by having both call independent
> methods. The second option might lead to slightly more efficient code, but
> for operations such as indexOf() I do not think this would matter in
> practice. On the other hand, the second option might lead to more confusing
> stack traces if people are debugging their code. In any case, if we decide
> to go for the second option, I would however like us to move most of these
> freestanding methods into a (hidden) namespace.

That's probably partially solving (a) and making the best code generation for 
user code, at the expense of either increasing code size in QtCore by having 
more entry points or by inlining everything in qstring.h. Either way, it's not 
solving (b): maintenance will be higher by increasing duplication of code.

Just look at how much of QString's API is *not* in QStringRef aven after 10 
years that it has existed.

> Another point that hasn’t been discussed yet, is how to handle QStringRef.
> In my opinion, we should deprecate it, but it’s used quite a bit in some
> parts of our API (QXmlStreamReader comes to my mind). It would be good to
> also think about how to solve that case. QStringRef has a pointer to a
> QString, but does not increase the refcount of it. So it looks like we can
> simply make it an alias for QStringView. That would break the
> QStringRef::string() method (which we should probably deprecate in 5.10 to
> prepare for the change), but everything else should stay compatible.

We can't... I tried that a while ago and it broke QXmlStreamReader and other 
places badly. The issue is that they expect QStringRef to continue to be valid 
after mutating the QString it was bound to. That works because of the pointer 
to the QString, as opposed to a pointer to the data. And that's just what I 
found by after changing QStringRef a few years ago to be like QStringView 
today and simply running Qt Creator.

We can port away from QStringRef and into QStringView as we go by and where 
it's safe. But unless we're willing to refactor some code substantially. 
Unfortunately, it's very likely we can't begin this work now as it would break 
the QStringRef API and thus be BIC/SIC.

So, yes, deprecate, but we'll have to carry QStringRef for some time, like 
QRegExp.

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