Пишу по памяти, так как под рукой сейчас нет компилятора и исходников.

1. Какие типы можно использовать в качестве атрибутов у rule, при использовании оператора %= ? Например, можно ли использовать любой тип, у которого есть неявный конструктор от того типа, который формируется автоматически?

2. При использовании |, генерируется boost::variant. Что происходит, если у парсеров-аргументов одинаковый генерируемый тип? Например, double_ | ('x' >> double_). Как их отличать, если не использовать semantic actions?

3. Есть следующее rule: number %= ulong_long | long_long | double_. Генерируется boost::variant<UInt64, Int64, Float64>. (Здесь для удобства использую typedef unsigned long long UInt64; typedef long long Int64; typedef double Float64. Но при компиляции (gcc 4.3) возникает неоднозначность при инициализации boost::variant.
Пытаюсь написать так: number = ulong_long[_val = UInt64(_1)] | long_long[_val = Int64(_1)] | double[_val = Float64(_1)], но ругается, что нет соответствующего оператора присваивания. Как разрешить неоднозначность и почему так не работает?

4. Предположим, нужно распарсить выражение, содержащие операторы и скобки. Операторы могут иметь различные приоритеты, скажем, 10 штук. Прийдётся ли писать что-то типа
op_expr = op_expr10 | op_expr9 | op_expr8 | ..., или можно проще? Что делать, если хочется в отдельном месте программы определить список операторов с заданными обозначением, арностью, приоритетом, ассоциативностью, а потом использовать эти данные в грамматике?

5. Непонятно, зачем в агрументе шаблона для rule и grammar указывать space_type, а потом в функции phrase_parse указывать ещё skipper grammar? Какой смысл у первого, если я и так указываю, что пропускать? Если убрать везде space_type, то, вроде бы, ничего не меняется.

Пишу по памяти. Ответы не претендуют на 100% правильность, так как пользуюсь эпизодически.
1. любой тип, который можно привести к типу правила.
2. будет один тип, не variant. Их можно различить только в semantic action.
3. здесь скорее всего проблема в том, что он не может различить типы ULong64 и Long64. есть подозрение, что ты используешь boost::lambda::_1 вместо boost::spirit::phoenix::...::_1 (плейсхолдер где-то в этом неймспейсе)
4. в qi так не сработает, тк там используется PEG. каждая альтернатива должна различаться первыми терминальными символами.
5. чтоб каждому правилу можно было указать свой набор "пробельных символов". сперва "пробелы" убирает парсер фразы, потом убираются "пробелы" правила.

PS: по своему опыту могу сказать, не надо использовать spirit для сложных грамматик, слишком сложно в реализации, в отладке. Чего стоит понять вывод компилятора на ошибку .
я прототип грамматики создаю в antlrworks (http://www.antlr.org/download.html), потом переношу на spirit.

удачи в освоении spirit!

Здравствуйте, Аноним, Вы писали:

А>Пишу по памяти. Ответы не претендуют на 100% правильность, так как пользуюсь эпизодически.
А>1. любой тип, который можно привести к типу правила.
А>2. будет один тип, не variant. Их можно различить только в semantic action.
А>3. здесь скорее всего проблема в том, что он не может различить типы ULong64 и Long64. есть подозрение, что ты используешь boost::lambda::_1 вместо boost::spirit::phoenix::...::_1 (плейсхолдер где-то в этом неймспейсе)
Использую boost::spirit::qi::_1, вроде это то же, что из phoenix-а. (по крайней мере, ругается на phoenix )
А>4. в qi так не сработает, тк там используется PEG. каждая альтернатива должна различаться первыми терминальными символами.
А>5. чтоб каждому правилу можно было указать свой набор "пробельных символов". сперва "пробелы" убирает парсер фразы, потом убираются "пробелы" правила.

А>PS: по своему опыту могу сказать, не надо использовать spirit для сложных грамматик, слишком сложно в реализации, в отладке. Чего стоит понять вывод компилятора на ошибку .
Да, потребовалась пара дней, чтобы только скомпилировать то, что я хочу

А>я прототип грамматики создаю в antlrworks (http://www.antlr.org/download.html), потом переношу на spirit.
А зачем переносить на spirit? Может, проще использовать напрямую ANTLR, или что-нибудь ещё? (пока ничего кроме spirit не пробовал) Какие серьёзные недостатки по сравнению со spirit-ом (насколько сложно интегрировать в программу на C++?)

А>удачи в освоении spirit!
Спасибо!

Здравствуйте, Аноним, Вы писали:

А>Использую boost::spirit::qi::_1, вроде это то же, что из phoenix-а. (по крайней мере, ругается на phoenix )
Лучший способ решения подобных проблем в моем случае было переписать тоже самое с пошаговой проверкой.

А>Да, потребовалась пара дней, чтобы только скомпилировать то, что я хочу
Вот-вот. Потому сложную грамматику лучше писать на чем то другом. Если скорость не важна и можно использовать java, то antlr, по моему мнению, — лучший выбор.

А>А зачем переносить на spirit? Может, проще использовать напрямую ANTLR, или что-нибудь ещё? (пока ничего кроме spirit не пробовал) Какие серьёзные недостатки по сравнению со spirit-ом (насколько сложно интегрировать в программу на C++?)
Я одновременно пытался сделать и на antlr, и на spirit. На spirit получилось быстрее реализовать семантику, а на antlr — прототип грамматики. На том и остановился.