Il 27/03/2017 17:46, Thiago Macieira ha scritto: > >> 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.
QRegularExpressionMatch has a similar problem: it currently stores a
copy of the subject string passed to
QRegularExpression::match(QString/QStringRef). People are relying on
this behaviour, including its own autotests; for instance, this works:
> QRegularExpression re("\\d+");
> auto m = re.match("foo123bar"); // stores a copy
> assert(m.captured(0) == "123"); // safe -- extracts substring from
> internal copy
Questions:
1) Should this behaviour be deprecated and eventually changed? How to
make users aware of this behaviour change?
2) Suppose we add right now a match(QStringView) overload, should it
still return a QRegularExpressionMatch or a new class with similar API?
If it still returns a QREM, what would QREM::capturedRef(N) then return
for a match over a string view?
(Trying to find the path of least breakage)
Cheers,
--
Giuseppe D'Angelo | [email protected] | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
