Boost::spirit и иже с ним.

[Bepec]

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

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

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

Итак, boost::spirit.

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

+:

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

-:

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

[navrocky]

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

[m_ax]

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

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

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

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

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

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

[Bepec]

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

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

[Old]

Там проблема с памятью, если почитать в статье - просто забитие памяти. Количество значения вроде не имеет

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

[VPS]

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

[Bepec]

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

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

[Old]

ссылка на хабр приведена. Можете подискутировать с автором той темы

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

но хабру я верю больше, чем вам

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

[Bepec]

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

[Old]

Там по делу, а вы как всегда "куда то в сторону коровы стреляет" ©

Да нет, в сторону "куда-то вы стреляете" этой ерундой:

Там проблема с памятью, если почитать в статье - просто забитие памяти.

Совершенно не понимая того, о чем пишите. Ну как всегда.

[kamre]

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

Был опыт работы со 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.

[Bepec]

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

[Igors]

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

[Fregloin]

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