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

Giuseppe D'Angelo dangelog at gmail.com
Sat Feb 25 03:48:11 CET 2012


2012/2/22 Thiago Macieira <thiago at kde.org>:
> The uses of QRegExp in qtbase and my proposals would be:

In short, the biggest deal is how to properly replace QString methods;
since everywhere else (QVariant, QObject, QStringList,
QSortFilterProxyModel) you want it to be replaced by the new class, or
a new class to be added.

I'm evaluating these approaches:

1) add the operator QRegularExpression() const to QRegExp and remove
the QString overloads taking a QRegExp:
Drawbacks:
* possible subtle bugs introduced by the different QRegExp and
QRegularExpression behaviours/quirks/syntax support/etc.
* decide what to do with the overloads taking a non-const-ref QRegExp
(used to extract captures, matched length, etc.)
* ... fix QRegExp. Right now it is bugged, and things like

    QRegExp re("...");
    /* do something like string.indexOf(re),
    which does not actually *use* re,
    but it just converts it to QRegularExpression */
    re.matchedLength();

will crash (I have a patch that I think fixes it, but I don't know
what it *exactly* does... who's the QRegExp maintainer?)

2) Go with something like

    template <typename RE> inline QT_DEPRECATED QString &replace(const
RE &rx, const QString &after, typename RE::isQRegExp * = 0)
    {
        // inline implementation, or call a method exported by the
QRegExp library
    }

Pro
  * Should be 100% compatible
Drawbacks
  * str.replace(re, "foo") doesn't compile any more -- it's not found
during template lookup, since no overload is found taking (QRegExp,
const char[3]). That is, more template black magic is required for
each and every parameter but the first, to enable implicit
conversions. Help! :)

Comments?
-- 
Giuseppe D'Angelo



More information about the Development mailing list