[Development] QRegularExpressionMatch (was: Re: QList)

Marc Mutz 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
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts

More information about the Development mailing list