Choose between QRegExp or boost regular expressions?

Flurite

Sorry for the bump of this post, but would you suggest using the QRegExp Library or the Boost library for regular expressions/parsing?

goetz

[I've split your question off to a separate thread, as it was only loosely related to the original one, Volker]

There is no definite answer to this question (as to almost ever programming related question). It depends on the features you need for your regexp and your willingness to add another library.

Some hints for taking the decision:

If QRegExp fits your need, go with it. If it doesn't but boost does, go with boost.
If it's hard to add another library (probably for that regexp thingy only), stick with Qt.
If you run into performance issues with QRegExp, consider boost. But that can be measured only in your real world application or some test scenario that resembles your real world app. Guessing will most probably lead you to false decisions.

Flurite

Do both have the same capabilities?

goetz

To my knowledge, QRegExp has some limitations and does not support all that, for example, preg provides. I don't know boost regexp, so I cannot compare those two.

Flurite

bq. To my knowledge, QRegExp has some limitations and does not support all that, for example, preg provides. I don’t know boost regexp, so I cannot compare those two.

Alright, I guess I'll play around with QRegExp for now.. but I do have another question about capturing strings of text. It seems that before using the cap() function, it is MANDATORY that you call the indexIn() function for some reason.

For example, this works:

@void captures()
{
QString testString1("OMG"); QRegExp acronym("([A-Z]{1,})");
acronym.indexIn(testString1);

cout << (acronym.cap(1)).toStdString() << "\n\n";

}@

but this doesn't..

@void captures()
{
QString testString1("OMG"); QRegExp acronym("([A-Z]{1,})");

cout << (acronym.cap(1)).toStdString() << "\n\n";

}@

Does anyone know why?

goetz

How should the second version give any result? acronym never got in touch with testString, how should it know about its contents? You could even remove the testString definition completely and don't get a compiler error!

Flurite

bq. How should the second version give any result? acronym never got in touch with testString, how should it know about its contents? You could even remove the testString definition completely and don’t get a compiler error!

Silly me.. is there a specific function that connects the regular expression to the string?

lgeyer

Yes, QRegExp::indexIn() ;-)

In addition, you might use QRegExp::exactMatch() if you just want to match and you do not need any capture groups.

As to your actual question: keep in mind that Qt probably requires you to use QRegExp instead of any other third-party implementation, for example when using QRegExpValidator. If you just do plain pattern matching stick to Volkers advice and benchmark first. If there is no bottleneck go stick with Qt, as this means one worry less.

andre

If you are considdering using a different library, I would seriously considder using PCRE. The reason is that this is the library that will be used in Qt 5's new QRegularExpression & friends. If you use the same underlying library, you will likely experience less issues with porting over your expressions to the new framework when you decide to switch.

ixSci

boost regexp is much better than Qt one because it is PCRE compliant and QRegExp is not.
But you have even better option: just use state of the art compiler and use std::regexp since it is part of the C++11 standard.

goetz

While being PCRE compliant is a good point in favor of boost or std::regexp, it is not the killer argument that kicks QRegExp out of the game. Experience taught me that one gets to the limits of QRegExp and need to switch implementations only seldom. I personally never reached it.

So if your regular expressions are more or less "standard" (in the sense of "simple") one surely can profit from the integration of QRegExp with the rest of the Qt ecosystem (QString!)