giuseppe.dangelo at kdab.com
Mon Apr 3 00:36:32 CEST 2017
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
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
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)
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4007 bytes
Desc: Firma crittografica S/MIME
More information about the Development