[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