QRegularExpression的意外行为

Question

我刚刚开始切换到QRegularExpression，并使用它来标记具有多个分隔符可能性的字符串。我遇到了一种令人惊讶的行为，在我看来，这似乎是一种错误。我在Windows上使用QT5.5.1。

下面是示例代码：

#include <QRegularExpression>
#include <QString>
#include <QtDebug>

int main(int argc, char *argv[])
{
    Q_UNUSED (argc);
    Q_UNUSED (argv);
    QRegularExpression regex ("^ ");

    qDebug () << "Expected:    " << QString ("M 100").indexOf(regex);
    qDebug () << "NOT expected:" << QString ("M 100").indexOf(regex, 1);
    qDebug () << "Expected:    " << QString (" 100").indexOf(regex);

    QRegularExpression regex1 (" ");
    qDebug () << "Expected:    " << QString ("M 100").indexOf(regex1);
}

以及产出：

Expected:     -1
NOT expected: -1
Expected:     0
Expected:     1

如果将插入符号(^)与"indexOf“调用中的起始位置(0)一起使用，则会阻止表达式进行匹配。直观地，我期望插入符号与我指定的位置上的字符串匹配。相反，它根本不匹配。

我将切换我的标记以使用splitRref来避免这个问题。尽管这可能稍微干净一些，但我需要了解这是否是正确的行为，还是应该向Qt报告一个bug。

更新:使用splitRef并不能完全解决我的问题，因为我需要使用正则表达式来检测某些标记是否是浮点数，并且不能在QStringRef中使用QRegularExpression。为了实现这种可能性，我必须将我的QStringRef令牌转换为一个实际的QString，而这正是我最初想要避免的。

Answer 1

^在主题字符串的开头或在多行模式下的换行符之后匹配。偏移量不会改变这些语义。因此，在偏移量1处将/^ / (以regex表示法)与M 100进行匹配，结果不匹配。

也许你想要\G？来自pcrepattern(3)

\G匹配主体中的第一个匹配位置 只有当当前匹配位置位于匹配的起点时，\G断言才是正确的，这是由pcre_exec()的startoffset参数指定的。当startoffset值为非零时，它与\A不同.

这样，这个代码：

QRegularExpression regex ("\\G ");

qDebug () << "Expected:    " << QString ("M 100").indexOf(regex);
qDebug () << "NOT expected:" << QString ("M 100").indexOf(regex, 1);
qDebug () << "Expected:    " << QString (" 100").indexOf(regex);

版画

Expected:     -1
NOT expected: 1
Expected:     0