[Development] QTBUG-23489: Implement the new regular expression classes using PCRE

Giuseppe D'Angelo dangelog at gmail.com
Wed Feb 22 18:51:07 CET 2012


On 22 February 2012 17:11,  <lars.knoll at nokia.com> wrote:
> Hi,
>
> this is the first mail where I'd like to go through the remaining features
> for Qt 5.0.
>
> I know that this bug is blocked by not having PCRE in 3rdparty/. But how
> is the status apart from this?

The "final" reviews (API, code, tests, docs) are missing, as well as
the big rename to QRegex (or whatever).
I think the code is more or less OK, apart the usual cleanups, but I
defer to your judgement :)

> Thiago, simply tell me if you feel
> comfortable with the code and I'll do final review and approval. If it
> doesn't break BC and is standalone from other code in qtcore, it can go
> into master, otherwise I'd prefer it to go into api_changes.

It doesn't break BC or SC in any classes, it's a pure API addition.
The proposed rename to QRegex of course will break stuff, but as of
now noone is using those methods because they're not available -- the
patches are not merged ;-)
Or did you mean something else?
The bigger issue was related to (re)moving QRegExp: make
QString::indexOf/replace/etc. templated (on the regexp class). I can't
estimate the breakage that would do.

> There's another related issue to this bug: What do we do with the old
> QRegExp? I've gripped through our code and removing it is a larger
> surgical operation.

There are certain places where QRegExp in which the maintainer doesn't
want to depend on PCRE; for instance, qmake. In most of other places,
the replacement is simply a s/QRegExp/QRegularExpression/.

The only points where the API isn't a replecement is where the other
non-Perl QRegExp matchings are used (f.i. wildcard matching; but I saw
that QRegExp has a nice wc2rx internal method to convert wildcards to
a Perl-like regex, that could potentially even be exposed as part of
QRegularExpression API, and that can help the conversion...).

> So I'd propose that we now bite the bullet and leave it in QtCore. Let's
> simply mark it as deprecated since 5.0, and live with the additional 100k
> in QtCore.

Can it eventually become private in 5.0, accessible only through a
public interface in the "qt4support" repository (or whatever is called
the place where QHttp, QFtp etc. will go), and then get (re)moved from
QtCore later without anyone noticing?

Cheers,
-- 
Giuseppe D'Angelo



More information about the Development mailing list