Discussion:
QRegExp in Qt 5 (was: V8 import to QtBase)
Giuseppe D'Angelo
2011-09-04 19:31:50 UTC
Permalink
I think maybe it's better to continue the discussion on a separate thread?

Apparently everyone agrees that QRegExp needs improvements and fixups,
but what exactly are the expectations for the default regexp engine
for Qt5? Since (apparently) the discussion is still going on, it seems
to me that no consensus has been reached yet.

So, please, discuss: what are the features people want to be supported
in 5.0? What to do with the current engine (keep it as the default in
order not to break anything, or change it to the RegExp2
implementation, or overhaul it, etc.)? Did anyone do some research
with an alternative engine implementation (PCRE, ICU, V8, etc.) and
can provide some results?

Cheers,
--
Giuseppe D'Angelo
Pau Garcia i Quiles
2011-09-04 19:43:10 UTC
Permalink
Hi,

PCRE is the "reference implementation" for regular expressions. There
is a C version, and it includes a C++ binding (pcrecpp) originally
developed by Google. IIRC there are a few cases where PCRE exhibits
exponential complexity. I have used pcrecpp in a few projects and it
is really easy to use, even easier than QRegExp.

Then there are a few implementations more. Google developed one called
re2 ( http://code.google.com/p/re2/ ) that is allegedly faster and
leaner than PCRE. How does it cope with those cases where PCRE had
exponential complexity? It does not implement them.

About the others, I do not have any experience.
Post by Giuseppe D'Angelo
I think maybe it's better to continue the discussion on a separate thread?
Apparently everyone agrees that QRegExp needs improvements and fixups,
but what exactly are the expectations for the default regexp engine
for Qt5? Since (apparently) the discussion is still going on, it seems
to me that no consensus has been reached yet.
So, please, discuss: what are the features people want to be supported
in 5.0? What to do with the current engine (keep it as the default in
order not to break anything, or change it to the RegExp2
implementation, or overhaul it, etc.)? Did anyone do some research
with an alternative engine implementation (PCRE, ICU, V8, etc.) and
can provide some results?
Cheers,
--
Giuseppe D'Angelo
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
Thiago Macieira
2011-09-04 19:53:42 UTC
Permalink
Post by Giuseppe D'Angelo
I think maybe it's better to continue the discussion on a separate thread?
Apparently everyone agrees that QRegExp needs improvements and fixups,
but what exactly are the expectations for the default regexp engine
for Qt5? Since (apparently) the discussion is still going on, it seems
to me that no consensus has been reached yet.
So, please, discuss: what are the features people want to be supported
in 5.0? What to do with the current engine (keep it as the default in
order not to break anything, or change it to the RegExp2
implementation, or overhaul it, etc.)? Did anyone do some research
with an alternative engine implementation (PCRE, ICU, V8, etc.) and
can provide some results?
The main feature we want is to not write our own engine. We want to use an
existing, proven engine.

The idea to use JS syntax has a lot of benefits. It's an established standard
and we need to have it anyway, due to QtScript, QtWebKit and QtDeclarative.

But from my point of view, C++ developers expect to have something with the
Perl syntax and its features.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
BRM
2011-09-06 15:44:20 UTC
Permalink
----- Original Message -----
Sent: Sunday, September 4, 2011 3:53 PM
Subject: Re: [Qt5-feedback] QRegExp in Qt 5 (was: V8 import to QtBase)
Post by Giuseppe D'Angelo
I think maybe it's better to continue the discussion on a separate
thread?
Post by Giuseppe D'Angelo
Apparently everyone agrees that QRegExp needs improvements and fixups,
but what exactly are the expectations for the default regexp engine
for Qt5? Since (apparently) the discussion is still going on, it seems
to me that no consensus has been reached yet.
So, please, discuss: what are the features people want to be supported
in 5.0? What to do with the current engine (keep it as the default in
order not to break anything, or change it to the RegExp2
implementation, or overhaul it, etc.)? Did anyone do some research
with an alternative engine implementation (PCRE, ICU, V8, etc.) and
can provide some results?
The main feature we want is to not write our own engine. We want to use an
existing, proven engine.
The idea to use JS syntax has a lot of benefits. It's an established standard
and we need to have it anyway, due to QtScript, QtWebKit and QtDeclarative.
But from my point of view, C++ developers expect to have something with the
Perl syntax and its features.
Most of the tools I come across when working with RegEx use the PERL syntax.
So from a standpoint of consistency, the PERL syntax is expected.

At least I personally don't see any issue that JS related stuff (QtSCript, QtWebKit, QtDeclarative) should use the JS syntax;
while the C++ developers (etc.) uses the PERL syntax.

That said, my biggest issue with the current QRegExp is that it doesn't support most of RegEx.
So I end up figuring out the RegEx in a standard tool, then testing and retesting with Qt until I get something QRegExp supports that provides the expected behavior.

So, regardless of what syntax ultimately is used, having full RegEx support would be a very good thing that would reduce a lot of headaches.

I do agree that this is something that should be sourced from an external library if at all possible.
Perhaps for Boost RegEx (http://www.boost.org/doc/libs/1_47_0/libs/regex/doc/html/index.html) would be a good choice for some standardization?
It also supports various syntax implementations at least according to the docs listed there. (No, I haven't used it. This is just a thought.)

$0.02

Ben
Kent Hansen
2011-09-05 06:56:33 UTC
Permalink
Post by Giuseppe D'Angelo
I think maybe it's better to continue the discussion on a separate thread?
Apparently everyone agrees that QRegExp needs improvements and fixups,
but what exactly are the expectations for the default regexp engine
for Qt5? Since (apparently) the discussion is still going on, it seems
to me that no consensus has been reached yet.
Agreed. There's also https://bugreports.qt.nokia.com/browse/QTBUG-20888
-- that's a good place to add concerns and alternatives discussed here,
so they don't get "lost".

Kent
Olivier Goffart
2011-09-06 16:43:25 UTC
Permalink
Post by Giuseppe D'Angelo
I think maybe it's better to continue the discussion on a separate thread?
Apparently everyone agrees that QRegExp needs improvements and fixups,
but what exactly are the expectations for the default regexp engine
for Qt5? Since (apparently) the discussion is still going on, it seems
to me that no consensus has been reached yet.
So, please, discuss: what are the features people want to be supported
in 5.0? What to do with the current engine (keep it as the default in
order not to break anything, or change it to the RegExp2
implementation, or overhaul it, etc.)? Did anyone do some research
with an alternative engine implementation (PCRE, ICU, V8, etc.) and
can provide some results?
Cheers,
There is also the std::regex in C++11, which should work with QString and
QByteArray.
http://en.wikipedia.org/wiki/C++11#Regular_expressions
Thiago Macieira
2011-09-06 18:02:45 UTC
Permalink
Post by Olivier Goffart
There is also the std::regex in C++11, which should work with QString and
QByteArray.
http://en.wikipedia.org/wiki/C++11#Regular_expressions
Then I think we should support the same syntax, regardless of the engine, if
possible.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
m***@nokia.com
2011-09-07 08:57:17 UTC
Permalink
1. It is impossible to do big changes to QRegExp without breaking existing code. Please keep the compatibility goals of Qt5 in mind. Remember that we want to MINIMIZE breakage and not repeat Qt3 to Qt4.
2. While it might be interesting to write yet-another regular expression engine, there seem to be more exciting projects around, given that the problem has been solved a couple of times already.

So why not keep QRegExp as it is? Benefit: no breakage, and existing use cases work OK. If we think that using javascript or boost is not sufficient for new code, and we need to wrap an existing engine with a Qt-style API, we can do that as a separate module. If that turns out OK and is accepted, we can then consider to merge whatever new regexp class we come up with QRegExp for Qt 6.

But do we *really* need that? In the longer run, wouldn't it be better to merge the other C++ efforts with Qt? Instead of yet another generation of Qt tools, why not make Qt more friendly towards std::?

Matthias


-----Original Message-----
From: qt5-feedback-bounces+matthias.ettrich=***@qt.nokia.com [mailto:qt5-feedback-bounces+matthias.ettrich=***@qt.nokia.com] On Behalf Of ext Thiago Macieira
Sent: Dienstag, 6. September 2011 20:03
To: qt5-***@qt.nokia.com
Subject: Re: [Qt5-feedback] QRegExp in Qt 5 (was: V8 import to QtBase)
Post by Olivier Goffart
There is also the std::regex in C++11, which should work with QString
and QByteArray.
http://en.wikipedia.org/wiki/C++11#Regular_expressions
Then I think we should support the same syntax, regardless of the engine, if possible.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Will Stokes
2011-09-07 12:10:34 UTC
Permalink
I tend to agree with Matthias. At this point I'm making use of QRegExp
all over my software and it's doing just fine by me. This whole
conversation was actually a bit of a surprise to me. I would not enjoy
converting all my regular expressions from Perl to Javascript syntax.
If any change does occur it seems to make sense to use C++11 or std::.
Increasing the size of QtCore isn't attractive either.

-Will
Post by m***@nokia.com
1. It is impossible to do big changes to QRegExp without breaking existing code. Please keep the compatibility goals of Qt5 in mind. Remember that we want to MINIMIZE breakage and not repeat Qt3 to Qt4.
2. While it might be interesting to write yet-another regular expression engine, there seem to be more exciting projects around, given that the problem has been solved a couple of times already.
So why not keep QRegExp as it is? Benefit: no breakage, and existing use cases work OK. If we think that using javascript or boost is not sufficient for new code, and we need to wrap an existing engine with a Qt-style API, we can do that as a separate module. If that turns out OK and is accepted, we can then consider  to merge whatever new regexp class we come up with QRegExp for Qt 6.
But do we *really* need that? In the longer run, wouldn't it be better to merge the other C++ efforts with Qt? Instead of yet another generation of Qt tools, why not make Qt more friendly towards std::?
Matthias
-----Original Message-----
Sent: Dienstag, 6. September 2011 20:03
Subject: Re: [Qt5-feedback] QRegExp in Qt 5 (was: V8 import to QtBase)
Post by Olivier Goffart
There is also the std::regex in C++11, which should work with QString
and QByteArray.
http://en.wikipedia.org/wiki/C++11#Regular_expressions
Then I think we should support the same syntax, regardless of the engine, if possible.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Software Architect - Intel Open Source Technology Center
     E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Thiago Macieira
2011-09-07 13:17:17 UTC
Permalink
Post by m***@nokia.com
1. It is impossible to do big changes to QRegExp without breaking existing
code. Please keep the compatibility goals of Qt5 in mind. Remember that we
want to MINIMIZE breakage and not repeat Qt3 to Qt4.
I wasn't asking any changes to QRegExp. The idea is to move that class, in its
entirety, to a separate library. That way, people using it will have the
current behaviour and even keep source compatibility.

The challenge will be to deal with the QString methods that take QRegExp.
Probably mark them inline and implement them in the qregexp.h header (which is
in the other library).
Post by m***@nokia.com
2. While it might be
interesting to write yet-another regular expression engine, there seem to
be more exciting projects around, given that the problem has been solved a
couple of times already.
And I wholeheartedly agree. Let's not write another engine. Let's use an
existing engine.

The question is only which one.
Post by m***@nokia.com
So why not keep QRegExp as it is? Benefit: no breakage, and existing use
cases work OK. If we think that using javascript or boost is not sufficient
for new code, and we need to wrap an existing engine with a Qt-style API,
we can do that as a separate module. If that turns out OK and is accepted,
we can then consider to merge whatever new regexp class we come up with
QRegExp for Qt 6.
That's one option. The drawback is, of course, that QRegExp is slow, hardly
maintained (Jasmin used to maintain it) and has a non-standard syntax. There's
absolutely no one who wants to implement advanced features like forward
lookahead. Like you said yourself, there are more exciting projects aroudn.

So in my opinion, a replacement class that wraps around an *existing* engine
is a lot more interesting. The four engines that have been discussed so far
are:

- V8's
- PCRE
- boost::regex
- std::regex
Post by m***@nokia.com
But do we really need that? In the longer run, wouldn't it be better to
merge the other C++ efforts with Qt? Instead of yet another generation of
Qt tools, why not make Qt more friendly towards std::?
We should. But at this time, std::regex is not standard. There's simply no way
we can use it everywhere. As of GCC 4.6, support is incomplete.

boost::regex is a 1 MB library that pulls in three ICU dependencies. I don't
know if our own ICU usage pulls in any of those three. Denis to confirm.

The engine in V8 carries the problems of the thread.

PCRE is fairly small, but it only operates in UTF-8. It would be an
interesting challenge to convert the index positions in the UTF-8 string back
to QString indexes.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
BRM
2011-09-07 13:32:57 UTC
Permalink
----- Original Message -----
Sent: Wednesday, September 7, 2011 9:17 AM
Subject: Re: [Qt5-feedback] QRegExp in Qt 5 (was: V8 import to QtBase)
Post by m***@nokia.com
1. It is impossible to do big changes to QRegExp without breaking existing
code. Please keep the compatibility goals of Qt5 in mind. Remember that we
want to MINIMIZE breakage and not repeat Qt3 to Qt4.
I wasn't asking any changes to QRegExp. The idea is to move that class, in its
entirety, to a separate library. That way, people using it will have the
current behaviour and even keep source compatibility.
The challenge will be to deal with the QString methods that take QRegExp.
Probably mark them inline and implement them in the qregexp.h header (which is
in the other library).
I don't know that putting it in a separate library would be a resolution then if there are dependencies in QString.
That said, I think there is a rather simple solution.

The Boost Library API supports naming the convention being used. We could do the same (whether we use Boost or not), and have the default convention be the old style.
If you want the new features, then you have to specify one of the other conventions. At some point (Qt6?) the default could be changed to something more standard.
 
That would keep the compatibility requirement intact, and give the enhancements desired.

$0.02

Ben
Simon Hausmann
2011-09-07 13:56:05 UTC
Permalink
On Wednesday, September 07, 2011 03:17:17 PM ext Thiago Macieira wrote:
[...]
Post by Thiago Macieira
The engine in V8 carries the problems of the thread.
Out of curiousity, what is the problem of the thread?



Simon
Thiago Macieira
2011-09-07 16:56:12 UTC
Permalink
Post by Simon Hausmann
[...]
Post by Thiago Macieira
The engine in V8 carries the problems of the thread.
Out of curiousity, what is the problem of the thread?
Not a threading problem.

I meant "the problems described in this email thread".
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Oswald Buddenhagen
2011-09-07 13:26:57 UTC
Permalink
Did anyone do some research with an alternative engine implementation
(PCRE, ICU, V8, etc.) and can provide some results?
yes, an intern in the trolltech berlin office - in summer 2008.
here is the text ((mostly) verbatim cwiki source code) and a tar
file with some experimental sources.
of course it does not cover all current contenders and the numbers are
probably somewhat outdated.

<noautolink>
---+!! Regular Expressions and Qt

%TOC%

---++ Current Issues with QRegExp

---+++ High Level
* QRegExp API is broken
* see *T7* in [[#Low_Level][Low Level]]
* QRegExp is used for QtScript thought it does not fullfill the ECMAScript specification ([[http://www.ecma-international.org/publications/standards/Ecma-262.htm][ECMA-262-1999]]). Missing features include
* Non-greedy quantifiers (see page 141 titled "- 129 -")
* Patternist/XPath also needs Regex features not found in QRegExp, including
* Non-greedy quantifiers ([[http://www.w3.org/TR/xpath-functions/#regex-syntax]])
* Qt Creator might want to offer multi-line Regex search- and replacing later. This cannot be efficient because of *T6* described below. GtkSourceView has exactly [[http://bugzilla.gnome.org/show_bug.cgi?id=134674#c1][that problem]]...
* Customer ***** complained about QRegExp (though I don't see what's their exact problem):
<blockquote style="margin-left:45px;background-color:#efefef;padding:7px 20px 7px 20px">
In their code they have RegExp? for matching emoticons. Unfortunately, they cannot use QRegExp? because of poor support for negative/positive lookahead. As a workaround they are using the PCRE (Perl Compatible Regular Expressions) library.
</blockquote>
* Public task request:
* Lookbehind (*T4*) ([[http://trolltech.com/developer/task-tracker/index_html?id=217916&method=entry][bug 217916]])
* Support for POSIX syntax ([[http://trolltech.com/developer/task-tracker/index_html?id=218604&method=entry][bug 218604]])
* Removing const modifiers (*T7*) ([[http://trolltech.com/developer/task-tracker/index_html?id=219234&method=entry][bug 219234]], [[http://trolltech.com/developer/task-tracker/index_html?id=209041&method=entry][bug 209041]])
* Non-greedy quantifiers (*T3*) ([[http://trolltech.com/developer/task-tracker/index_html?id=116127&method=entry][bug 116127]])

---+++ Low Level
* *T1*: ^ (caret) and $ (dollar) cannot match at each newline
* *T2*: . (dot) always matches newlines
* *T3*: lazy/non-greedy/reluctant quantifiers are not supported. this is not to be confused with minimal matching.
* *T4*: lookbehind is not supported (lookahead is)
* *T5*: lastIndexIn does not find that last match which indexIn would have found, e.g. lastIndexIn("abcd") for pattern ".*" returns 3, not 0
* *T6*: only linear input is supported, for a text editor like Kate this does not scale
* *T7*: QRegExp combines matcher and match object, despite the 1:n relation. As a consequence matching with a const QRegExp instance modifies a const object.

---++ Future (or what it could be)

---+++ Engines

---++++ Commonalities of Boost.Regex and PCRE
* (+) *T1*: ^ (caret) and $ (dollar) can be configure to match at each newline or not at runtime
* (+) *T2*: . (dot) can be configured to match newlines or not at runtime
* (+) *T3*: Support for non-greedy quantifiers
* (+) *T4*: Support for lookbehind

---++++ Boost.Regex
* (+) Can match text from a non-linear sources like an array of lines
* (+) An integration prototype is working already:
* With matcher-match separation (*T7*)
* On real QStrings or with non-linear input (*T6*)
* With indexIn and proper lastIndexIn implementation (*T5*)
* see [[#Current_status_of_Boost_Regex_in][Current status of Boost.Regex integration]]
* (--) Code size
* [[http://www.boost.org/doc/tools/bcp/bcp.html][bcp]] (which stands for "boost copy") helps to rip out Boost.Regex from a full Boost package
* Current metrics for Boost.Regex and all required Boost components are 565 files, 4.6 MB uncompressed.

---++++ PCRE
* (+) Code size: Code already shipped with Qt as it's used in Webkit
* No UTF-16 support upstream but in Webkit. // TODO Bridge to QStrings?

---+++ Strategies
Lists alternative strategy candidates to improve the current situation.

---++++ Core
Strategies integrating a new Regex engine and it's implemenatation in QtCore.
* (--) Increases the code and binary size of QtCore

---+++++ *C1*: Replace current Regexp/Regexp2 engines of QRegExp through another engine in general
RegExp currently comes with two different regex pattern syntaxes: "RegExp" and "RegExp2". The latter was introduced to fix a problem with the former without breaking compatibility:

"For historical reasons, quantifiers (e.g. '*') that apply to capturing parentheses are more "greedy" than other quantifiers. For example, the pattern 'a*(a)*' will match 'aaa' with cap(1) == 'aaa'." [[http://doc.trolltech.com/4.4/qregexp.html#capturing-text]]

I don't see how this behavior could be imitated by any other Regex library in general. If this is true and we need to keep this feature, we cannot replace QRegExp's "RegExp" engine but only put new engines next to it.

Also if we decide to replace an existing syntax/engine with a new one this will have big potential to break customer code (not API, but ABI in a way)


---+++++ *C1.1*: Replace current Regexp/Regexp2 engines of QRegExp through Boost.Regex
* (--) There is at least one small thing that QRegExp can do but Boost.Regex cannot: Back reference in a pattern can go to 10 or higher in QRegExp (e.g. "\\10") but only up to \9 in Boost.Regex (just as in Perl). If this is true (a) Boost.Regex cannot transparently replace QRegExp's "RegExp2" implementation unless we decide to reduced the number of back references to a maximum of 9.
* See C1

---+++++ *C1.2*: Replace current Regexp/Regexp2 engines of QRegExp through PCRE
* See C1

---+++++ *C2*: Put Boost.Regex as a new engine next to Regexp/Regexp2 in QRegExp

---+++++ *C3*: Put PCRE as a new engine next to Regexp/Regexp2 in QRegExp

---+++++ *C4*: C2 + C3
* (?) Language features too similar?

---++++ Module
Strategies centered around the creation of a new Qt module.
* (+) Does *not* increase the code or binary size of QtCore

---+++++ *M1*: Boost.Regex as a new module QtRegex

---+++++ *M2*: PCRE as a new module QtRegex

---+++++ *M3*: Boost.Regex *and* PCRE as a new multi-engine module QtRegex
* (?) Language features too similar?

---+++++ *M[4..6]*: M[1..3] + Loosely integrate new Regex API into QtCore (QString, ..[?]) through abstract classes
Could look like this:
* class QString
* bool contains(const QRegExp & rx) const;
* bool contains(const *QAbstractRegexEngine* &matcher) const;
* ..
* int indexOf(const QRegExp & rx, int from = 0) const;
* int indexOf(const *QAbstractRegexEngine* &matcher, int from = 0) const;
* ..

---++++ Labs

---+++++ *L1*: Publish Boost.Regex integration as a project on Trolltech Labs
* (+) We might get detailed feedback from customers
* (+) Customers get new (alpha or beta) Regex code earlier
* (+) We can still integrate the same code later

---++ Current status of Boost.Regex integration

---+++ Concepts
* Stay close to QRegExp where it doesn't hurt to make people feel at home
* Seperate matcher and match object
* One match/matcher pair for plain strings, another pair for non-linear input (from a "feeder")

---+++ Known todos
* try to get templates out of the feeder API in a smooth way
* integrate x-modifier (already supported by Boost.Regex)
* fix coding style violations
* d pointers

---+++ Open questions
* Better class names? @YOU: Ideas?

---+++ Binary size
.. of what currently is libQtRegex:

| *Linux 32Bit* |||
| *Symbols* | *Linking* | *Size* |
| Debug | Dynamic | 4,069,988 |
| Debug | Static | 4,280,300 |
| Release | Dynamic | 492,830 |
| Release | Static | 449,410 |
| Release/stripped | Static | 333,548 |

| *Windows 32Bit* |||
| *Symbols* | *Linking* | *Size* |
| Debug | Dynamic | 4,290,586 |
| Debug | Static | 4,845,780 |
| Release | Dynamic | 412,672 |
| Release | Static | 437,760 |
| Release/stripped | Static | 437,760 |

Legend:
* Dynamic - linked as shared library
* Static - linked as executable with demo code
* Size is in bytes

These number are
* for the Boost.Regex code and its Qt integration together
* still moving up and down a little ...

---+++ Public API
(without constructors)
* class *QRegexEngineBase*
* enum *AnchorMode*
* AnchorWontMatch
* AnchorAtStartEnd
* AnchorAtEachLine
* Qt::CaseSensitivity *caseSensitivity* () const;
* bool *isValid* () const;
* int *numCaptures* () const;
* QString *pattern* () const;
* void *setCaseSensitivity* (Qt::CaseSensitivity cs);
* void *setPattern* (const QString & pattern);
* class *QRegexEngine* : QRegexEngineBase
* QRegexMatch *exactMatch* (const QString & input, AnchorMode anchorMode = AnchorAtStartEnd) const;
* QRegexMatch *findFirst* (const QString & input, int startOffset = 0, int endOffset = -1, AnchorMode anchorMode = AnchorAtStartEnd) const;
* QRegexMatch *findLast* (const QString & input, int startOffset = 0, int endOffset = -1, AnchorMode anchorMode = AnchorAtStartEnd) const;
* QList&lt;QRegexMatch&gt; *findAll* (const QString & input, int startOffset = 0, int endOffset = -1, AnchorMode anchorMode = AnchorAtStartEnd) const;
* class *QRegexFeedEngine* &lt;feeder_type&gt; : QRegexEngineBase
* QRegexFeedMatch&lt;feeder_type&gt; *exactMatch* (feeder_type begin, feeder_type end, AnchorMode anchorMode = AnchorAtStartEnd) const;
* QRegexFeedMatch&lt;feeder_type&gt; *findFirst* (feeder_type begin, feeder_type end, AnchorMode anchorMode = AnchorAtStartEnd) const;
* QRegexFeedMatch&lt;feeder_type&gt; *findLast* (feeder_type begin, feeder_type end, AnchorMode anchorMode = AnchorAtStartEnd) const;
* QList&lt;QRegexFeedMatch&lt;feeder_type&gt; &gt; *findAll* (feeder_type begin, feeder_type end, AnchorMode anchorMode = AnchorAtStartEnd) const;
* class *QRegexMatchBase* &lt;T&gt; // &lt;T&gt; in {&lt;const ushort *&gt;, &lt;feeder_type&gt;}
* virtual QString *cap* (int nth = 0) const = 0;
* QStringList *capturedTexts* () const;
* int *count* () const;
* bool *isValid* () const;
* int *length* (int nth = 0) const;
* int *pos* (int nth = 0) const;
* class *QRegexMatch* : QRegexMatchBase &lt;const ushort *&gt;
* QString *cap* (int nth = 0) const;
* class *QRegexFeedMatch* &lt;feeder_type&gt; : QRegexMatchBase&lt;feeder_type&gt;
* QString *cap* (int nth) const;

---+++ Usage example <code><pre>#include &lt;qregexengine.h&gt;
#include &lt;qregexmatch.h&gt;
#include &lt;qregexfeedengine.h&gt;
#include &lt;qregexfeedmatch.h&gt;
#include &lt;stringlistregexfeeder.h&gt;

int main()
{
QStringList list;
list &lt;&lt; QString("hello");
list &lt;&lt; QString("happy");
list &lt;&lt; QString("world");
StringListRegexFeeder feeder(list);


// Plain string
QRegexEngine engineOne("(h[a-z]+){2}");
QRegexMatch matchOne = engineOne.exactMatch(list.join(""));
for (int j = 0; j &lt; matchOne.count(); j++) {
qDebug() &lt;&lt; "[" &lt;&lt; j &lt;&lt; "]" &lt;&lt; matchOne.cap(j);
}
qDebug() &lt;&lt; "";


// Complex feeder
QRegexFeedEngine&lt;StringListRegexFeeder&gt; engineTwo("(h[a-z]+){2}");
QRegexFeedMatch&lt;StringListRegexFeeder&gt; matchTwo = engineTwo.exactMatch(feeder.begin(), feeder.end());
for (int i = 0; i &lt; matchTwo.count(); i++) {
qDebug() &lt;&lt; "[" &lt;&lt; i &lt;&lt; "]" &lt;&lt; matchTwo.cap(i);
}
qDebug() &lt;&lt; "";

return 0;
}</pre></code>

</noautolink>
Loading...