Russian Qt Forum

Приветствую заглянувших. Имеющих баттхерт на эту тему, прощу закрыть глаза гантелями - и в теме тихо и руки накачаете :D

Собственно для чего тема? Попробовать что может спирит, какие у него есть + и -. Собственно буду дополнять первое сообщение, комментарии так и быть оставляю на откуп остальным.

Буду рад дополнительной информации.

Итак, boost::spirit.

Что это?
Spirit — одна из наиболее сложных частей Boost, предназначенная для написания парсеров напрямую в C++ тексте программы в виде, близком к форме Бэкуса-Наура.

+:

• Написание парсеров при помощи правил, возможность обойтись без regExp и велосипедов.
• Более простой для понимания код по сравнению с RegExp на больших проектах (6+ условий)

-:

• Большое время компиляции из-за реализации. Примерно 30 секунд на 4-7 правил и увеличивается пропорционально количеству правил.
• Большие траты памяти при компиляции. Невозможность использования более ~180-220 правил - компилятор завершается с нехваткой памяти http://habrahabr.ru/post/81175/ (http://habrahabr.ru/post/81175/). Т.е. для написания сложных парсеров нужно искать другой компонент.
• Сложность понимания кода в простых конструкциях (4-6 условий) по сравнению с RegExp и велосипедами. (Таки это недостаток, не спорьте :) )

Я думаю, проблемы с памятью можно решить, перейдя на 64 бит операционку %) ну и планок доставить

Spirit это не только парсеры.

Spirit состоит из трёх частей (не считая устаревший classic):
Spirit::Qi - это как раз по написанию парсеров,
Spirit::Karma - создание генераторов (представление данных в заданный формат)  
и Spirit::Lex - лексические анализаторы..

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

Одним из плюсов спирита считаю, пожалуй то, что он позволяет легко реагировать на какие то изменения в начальных условиях.
И сам код получается гораздо более прозрачен.

По поводу числа правил..
Реализация xml парсера (из примеров) содержит всего 5 правил.

Если речь идёт о парсерах, описание которых требует более 100 правил..
То да, тут мозг сломается, а не только компилятор)    

Там проблема с памятью, если почитать в статье - просто забитие памяти. Хотя можно многопоточно компилировать... :D  Попробовать можете :)

Потихоньку буду дополнять, по мере интереса.

Какое "забитие памяти"? :)
В далёкие времена 32-битных ОС, когда пользовательскому процессу было доступно всего несколько гигабайт адресного пространства, компиляторами часто его не хватало при компиляции сложных шаблонных конструкций.
На 64-битных платформах таких проблем нет, адресного пространства для процесса более чем достаточно.

Можно ещё здесь (http://kiri11.ru/boost_spirit_qi_part5) на русском почитать (там 5 частей)...

:) Old - ссылка на хабр приведена. Можете подискутировать с автором той темы, но хабру я верю больше, чем вам :)

to vps - спасибо, собственно я на него и наткнулся утром. Не так много русскоязычной документации :)

Да, но там нет ничего про "забите памяти". :) Нам не о чем будет дискутировать с автором. :)

Вот это и печально. Вы вместо того, что бы разобраться с вопросом и проверить самому - просто верите. :)
А хабр это да - авторитетное издание: на нем могут публиковать статьи все, даже вы. Поэтому, только "самые большие специалисты" ему верят. :)

Стоп оффтоп, привет адекватность.
Собственно по этой причине и верю больше :) Там по делу, а вы как всегда "куда то в сторону коровы стреляет" ©

Да нет, в сторону "куда-то вы стреляете" этой ерундой: :)
Совершенно не понимая того, о чем пишите. Ну как всегда. :)

Был опыт работы со spirit еще в времена его первой версии. Хотел сделать parser/viewer для тестов в одном рабочем проекте, тесты на некоем простом dsl. Фактически parser то уже был самописный, но код в нем был ужасный и не очень подходящий для viewer.

После 30-40 правил в грамматике spirit на ноутбуке с 2GB памяти и win32 без специального флага (3GB) даже не компилировалось. А с флагом залезало в своп и чрезвычайно медленно собиралось. В случае ошибки компиляции часто вываливало такую кучу, в которой разобраться очень сложно. Иногда internal compiler error и пляски с перегруппировкой кода для обхода. Времена были MSVC 2008.

В то же время разбирался с Java. На ней в итоге и сделал viewer. Использовал ANTLR3, у которого есть книжка с примерами и своя отдельная IDE для отладки грамматики и парсера. При этом в Eclipse с плагином для ANTLR все компилировалось мгновенно, compile on save. Ошибки в грамматике ANTLR выдавал понятные, в сгенерированном ANTLR коде IDE также сразу показывает ошибки. Намного удобнее и эффективнее получилось по сравнению с boost::sprit.

Благодарю за информацию.

Ну, правду сказать, мне spirit понравился. Не спорю - красивая идея, задумка. Но что из этого выйдет практически - хз. Задачи парсинга у меня возникают хаотично и довольно редко (ну может 2 раза в год). Если я вижу что могу все распарсить без затей за день/два - ну чего огород городить? Основные правила там освоить нетрудно, но найдется какая-нибудь "загогулина" не укладывающаяся в рамки - и долбайся потом с ней  :'( А вручную я уверен что порешаю. Словом, нужна подходящая ситуация - ну может когда-то (в будущем) случится. А пока "буду иметь ввиду"  :)

пользовался спиритом для парсинга json в qt 4.8.x. По скорости не сказал бы что мегабыстрый, перешел на родйной QJsonObject.