Парсинг строки определенного типа

[Igors]

Эти умозаключения вы выдаете потому, что понятия не имеете о регулярках. Да?

Ну чего Вы такой "нервный и желчный субъект" (как писали классики)? Не стоит отвечать сразу полагая что "все ясно, он НЕ ЗНАЕТ ". Поверьте, есть люди которые пытаются думать и анализировать, и это нормально

Вспомните тему про парсер BibTex.

А что собственно я должен вспоминать? Что я предложил нормальный код на C++ решающий задачу и доступный для дальнейшей поддержки и развития любому нормальному программисту? Так здесь мне стыдиться нечего  

[k0p4]

Во всех этих случаях Вам придется немало посуетиться с гордым/крутым "решением в 1 строку" и оно станет не таким уж простым. В то же время тупенький разбор "слово за словом" выдержит эту нагрузку без проблем.

Разбор "слово за словом" при новых условиях придётся модифаить. Как и регексп. Как и фаинд. А изменения не станут проблемой, в принципе, ни в одном из случаев.

[Old]

Ну чего Вы такой "нервный и желчный субъект" (как писали классики)?

А почему вы все время думаете что я нервно исхожу желчью?
Вы пишите очень наивные вещи, которые пугают исключительно вас. Это выглядит очень наивно, поэтому я и спросил.

А что собственно я должен вспоминать? Что я предложил нормальный код на C++ решающий задачу и доступный для дальнейшей поддержки и развития любому нормальному программисту? Так здесь мне стыдиться нечего  

Не, просто вы сразу поставили кучу условий и потребовали синтетические тесты на одном файле, которые кстати не прошли.

[Old]

ПС. Если кто-то заметил ошибки в коде, пожалуйста, сообщите. Я поправлю и проведу тесты повторно. Так же было-бы неплохо провести их хотя-бы на еще одной машине.

Попробуйте использовать не такие синтетические файлы.
Пусть со всех сторон могут быть разное число пробелов, табуляций и прочих комментариев. Что ближе к реальности.

[k0p4]

ПС. Если кто-то заметил ошибки в коде, пожалуйста, сообщите. Я поправлю и проведу тесты повторно. Так же было-бы неплохо провести их хотя-бы на еще одной машине.

Попробуйте использовать не такие синтетические файлы.
Пусть со всех сторон могут быть разное число пробелов, табуляций и прочих комментариев. Что ближе к реальности.

Таки ближе к реальности мои тесты. Например, у себя в проекте я писал парсер PLS файлов. PLS файлы от веб-сервиса, как правило, приходили без лишних пробелов, табов, и тд.

Сделал так, ничего кардинально не изменилось:

QVector<QString> GenerateList()
{
    QVector<QString> mVec;
    int counter = 0;
    for (size_t ix = 0; ix < 100000; ++ix)
    {
        if (counter == 5)
            mVec.push_back(QString("    -Y " + QString::number(qrand()) + " +X " + QString::number(qrand())));
        else if (counter == 10)
            mVec.push_back(QString("#-Y " + QString::number(qrand()) + " +X " + QString::number(qrand()) + "       b         "));
        else
            mVec.push_back(QString("-Y " + QString::number(qrand()) + " +X " + QString::number(qrand())));
    }
    return mVec;
}

[Igors]

Во всех этих случаях Вам придется немало посуетиться с гордым/крутым "решением в 1 строку" и оно станет не таким уж простым. В то же время тупенький разбор "слово за словом" выдержит эту нагрузку без проблем.

Разбор "слово за словом" при новых условиях придётся модифаить. Как и регексп. Как и фаинд. А изменения не станут проблемой, в принципе, ни в одном из случаев.

Не уверен. Предположим заданы такие правила (на мой взгляд совершенно простые и разумные)

X(Y) - задать абсолютное значение
+X(Y) - добавить к текущему значению
-X(Y) - отнять от текущего значения

Как порешать с regexp?

[Old]

Как порешать с regexp?

Почитать про регулярные выражения? 

[Igors]

Почитать про регулярные выражения? 

Так читайте, я ж Вам не запрещаю 

[Old]

Так читайте, я ж Вам не запрещаю 

Я уже почитал, поэтому такие наивные вопросы как у вас у меня и не возникают.

[Old]

Сделал так, ничего кардинально не изменилось:

Почему, вы рассчитываете, что вокруг "+X " " -Y " пробелы? Может там табуляции?
И чем больше будет таких "может" - тем больше вы будете добавлять проверок/условий.
А с регулярками вы просто будете чуть менять правила и то, если понадобиться.
По скорости - есть другие библиотеки с регуляркой, более быстрые чем в Qt. Зато вы получаете прозрачный код, который можно легко расширять с усложнением правил.

[Bepec]

Выражу мысль простую - если формат известен и не меняется, то любое решение с ним справится.

Если у формата имеются допущения и особенности, то простое решение выиграет. Ибо остальные будут являть собой регэксп или аналог и дополнительную обвязку

Универсального формата нет и не будет. И добавочные возможности приёма данных в 90% случаях избыточны. Ибо строится всё на формате. Без формата нет программы и нет регэкспа и нет рабочей версии. Профит Изменяемый формат = изменение любой программы.

Потому результат должен удовлетворять простым условиям. Если условия не проходят, строка/элемент отбрасываются.

[k0p4]

Может там табуляции?

А разница для кода какая будет? Если данные пришли не корректные - значит не корректные, - дропаем их.

И чем больше будет таких "может" - тем больше вы будете добавлять проверок/условий.

А регулярку и менять не надо! : )

А с регулярками вы просто будете чуть менять правила и то, если понадобиться.

А в коде я добавлю 1-2 дополнительных if`a.

По скорости - есть другие библиотеки с регуляркой, более быстрые чем в Qt.

Речь шла ИМЕННО про Qt. Ну и вряд ли они будут быстрей, чем простая реализация "в лоб".

Зато вы получаете прозрачный код, который можно легко расширять с усложнением правил.

ИМХО код без регулярок куда как прозрачней. И уж если речь зашла о поддержке, то код без регулярок куда проще поддерживать сторонним разработчикам, тем более низкоквалифицированным.

И вообще, в посте ТСа был вопрос как сделать это средствами Qt. Предложенное ТСом решение рабочее, но как мне кажется, не оптимальное. Регулярки конкретно для этой задачи не подходят - скорость в приоритете. Остаётся только решение в лоб, которое, кстати, показало лучшую скорость.

Вместо заключения:
Я не спорю с полезностью и удобность регулярок, но на таких мелких задачах больше подходит решение в лоб. Строго моё мнение : )

[Old]

А разница для кода какая будет? Если данные пришли не корректные - значит не корректные, - дропаем их.

А почему они не корректные? Табуляция такой же символ разделитель как и пробел.

А в коде я добавлю 1-2 дополнительных if`a.

Вот-вот. На каждый чих. А потому так в этом погрязните, что сами ничего не сможете разобрать.

ИМХО код без регулярок куда как прозрачней.

Это пока все так легко и просто. А теперь представьте, что выдернуть нужно не цифры, а номер телефон и email. Проверить их на валидность и выдернуть.

А так можно принять что в файле позиции чисел фиксированы:
-Y 00012 +X 01234
И выдергивать их из строку по точным смещениям: первое число - подстрока 3-7 символ; второе число - подстрока 11-15.
Ну а что, будет еще быстрей.

тем более низкоквалифицированным.

А ну тогда да. Про низкоквалифицированных поддержалщиков я уже писал свое мнение на форуме.

[Old]

на таких мелких задачах больше подходит решение в лоб. Строго моё мнение : )

Мелкие задачи имеют свойство сильно укрупняться.

[Bepec]

"Из пушки по воробьям" ©

Подобное уже встречалось в моей практике. Для 3 классов была создана фабрика классов, сериализация данных через S11n и ноды (что совсем не подходило для данных и приходилось костыли ставить). При том что парсер этого формата и эти классы я переписал за 2 дня. И вместо 1 непонятного и неописуемого класса, используеющего буст и s11n и Qt (описать мог только создатель) появились 3 класса, понятных всем.

PS "Самодокументируемость кода указывает на его простоту и гениальность" ©