[Development] QRegularExpressionMatch (was: Re: QList)
marc.mutz at kdab.com
Mon Apr 3 09:45:49 CEST 2017
On Monday 03 April 2017 04:59:27 Thiago Macieira wrote:
> On domingo, 2 de abril de 2017 15:36:32 PDT Giuseppe D'Angelo wrote:
> > > 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?
> Change what? The ability to run the code above? No.
> Whatever we do, we shouldn't break the code above.
> > 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?
> Anything that takes a QStringView and needs to store should store a
> QString, not a QStringView. So if it needs to make a copy, so be it.
This is an open question, one what the QT_STRINGVIEW_LEVELs are supposed to
help decide, so I strongly object to any blanket statement, in either
direction, from anyone, at this point.
> That's why I was proposing for QStringView to carry QString's d pointer if
> it knows it, so the refcounting can resume. Marc doesn't want that. So we
> need to have a QString overload for match(), if necessary.
The long-term goal here should be to not store a strong reference on matching.
How to get there is an open, and controversial, question. I'd make the
QStringView overload return a new class that does not store a strong
reference. But then the QString overload can't just go away with
QT_STRINGVIEW_LEVEL < 2, as usual (code comment necessary).
My original idea was to overload QStringView with QString&&. Whether that
works out in practice remains to be seen. It's becoming clearer and clearer
that just replacing QString/QStringRef overloads with a QStringView one won't
cut it. But when it doesn't, it points to interesting optimisation
oppporunities, like a missing QLatin1String or QStringBuilder<A,B> overload.
How does the existing match(QStringRef) overload handle lifetime?
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
KDAB - The Qt, C++ and OpenGL Experts
More information about the Development