info.stop.get_position() после вызова parse с невалидным буфером на ходится на начале самой верхней из вложенных рул. Хотелось бы получить позицию конкретного слова, вызвавшего неприятие.
On Sun, 05 Mar 2006 15:21:24 -0000, Grigory <10592@users.rsdn.ru> wrote:
> Имеются в виду ошибки во входных данных. > > info.stop.get_position() после вызова parse с невалидным буфером на ходится на начале самой верхней из вложенных рул. Хотелось бы получить позицию конкретного слова, вызвавшего неприятие.
Здравствуйте, MaximE, Вы писали:
ME>On Sun, 05 Mar 2006 15:21:24 -0000, Grigory <10592@users.rsdn.ru> wrote:
>> Имеются в виду ошибки во входных данных. >> >> info.stop.get_position() после вызова parse с невалидным буфером на ходится на начале самой верхней из вложенных рул. Хотелось бы получить позицию конкретного слова, вызвавшего неприятие.
ME>http://boost.org/libs/spirit/doc/debugging.html
Наверное, всё-таки, я не до конца точно выразился.
Мне НЕ НАДО ОТЛАЖИВАТЬ.
Мне надо вывести пользователю внятное сообщение об ошибке.
Здравствуйте, Grigory, Вы писали:
G>Имеются в виду ошибки во входных данных.
G>info.stop.get_position() после вызова parse с невалидным буфером на ходится на начале самой верхней из вложенных рул. Хотелось бы получить позицию конкретного слова, вызвавшего неприятие.
Можно попробовать сделать что-то вроде
(TYPE >> (
IDENTIFIER |
BRACE |
eps_p[error("жду скобку или идентификатор")])) |
CLASS_SPECIFIER |
EOF |
eps_p[error("жду функцию, переменную, класс или конец файла")]))
внутри функтора error — бросать исключение с описанием ошибки при вызове.
имхо, самое простое и понятное. Ну и eps_p[error("...")] можно для удобства сделать макросом.
к сожалению, используются исключения.
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, _Winnie, Вы писали:
_W>Здравствуйте, Grigory, Вы писали:
G>>Имеются в виду ошибки во входных данных.
G>>info.stop.get_position() после вызова parse с невалидным буфером на ходится на начале самой верхней из вложенных рул. Хотелось бы получить позицию конкретного слова, вызвавшего неприятие.
_W>Можно попробовать сделать что-то вроде
_W>
_W> (TYPE >> (
_W> IDENTIFIER |
_W> BRACE |
_W> eps_p[error("жду скобку или идентификатор")])) |
_W> CLASS_SPECIFIER |
_W> EOF |
_W> eps_p[error("жду функцию, переменную, класс или конец файла")]))
_W>
_W>внутри функтора error — бросать исключение с описанием ошибки при вызове. _W>имхо, самое простое и понятное. Ну и eps_p[error("...")] можно для удобства сделать макросом. _W>к сожалению, используются исключения.
Исключения не проблема. Проблема — количество правил. Одних только терминальных символов 50.
Трудоёмко и код превратиться в кашу. Хотелось бы штатного средства.
Думал переехать с флекса и бизона на спирит, да, видно, не судьба.
Здравствуйте, Grigory, Вы писали:
G>Здравствуйте, _Winnie, Вы писали:
_W>>Здравствуйте, Grigory, Вы писали:
G>>>Имеются в виду ошибки во входных данных.
G>>>info.stop.get_position() после вызова parse с невалидным буфером на ходится на начале самой верхней из вложенных рул. Хотелось бы получить позицию конкретного слова, вызвавшего неприятие.
_W>>Можно попробовать сделать что-то вроде
_W>>
_W>> (TYPE >> (
_W>> IDENTIFIER |
_W>> BRACE |
_W>> eps_p[error("жду скобку или идентификатор")])) |
_W>> CLASS_SPECIFIER |
_W>> EOF |
_W>> eps_p[error("жду функцию, переменную, класс или конец файла")]))
_W>>
_W>>внутри функтора error — бросать исключение с описанием ошибки при вызове. _W>>имхо, самое простое и понятное. Ну и eps_p[error("...")] можно для удобства сделать макросом. _W>>к сожалению, используются исключения.
G>Исключения не проблема. Проблема — количество правил. Одних только терминальных символов 50. G>Трудоёмко и код превратиться в кашу. Хотелось бы штатного средства. G>Думал переехать с флекса и бизона на спирит, да, видно, не судьба.
Ну а как ещё указывать, какая ошибка произошла, если не указать в грамматике её местонахождение? Ведь автоматически дать осмысленную дианостику при ошибке в правиле вроде (A >> C | B >> D) >> (X >> Y | Z >> T) невозможно?
Ну и если сделать макрос ERR, то синтаксического оверхеда на единицу осмысленных дейсвий будет вроде совсем немного.
Правильно работающая программа — просто частный случай Undefined Behavior
[кусь] _W>Ну а как ещё указывать, какая ошибка произошла, если не указать в грамматике её местонахождение? Ведь автоматически дать осмысленную дианостику при ошибке в правиле вроде (A >> C | B >> D) >> (X >> Y | Z >> T) невозможно?
Значит бизон умеет делать невозможные вещи? _W>Ну и если сделать макрос ERR, то синтаксического оверхеда на единицу осмысленных дейсвий будет вроде совсем немного.
Сравни
"syntax error, unexpected ACTIONLISTON_TOK, expecting END_PART_TOK in D:\WINNT\inf\wmp.adm(73)"
Боюсь никак. Да и трудно ожидать этого от LL парсера. Я и сам пытался получить от spirit'a внятные причины останова, но он упорно продолжал настаивать: ошибка где-то-там Вообще это конечно возможно, но потребует дикого изврата на экшенах и целой горы разных флагов, не стоит оно того. Да и не позиционируется spirit для создания парсеров чего-либо сложнее XML, это в первую очередь средство парсинга ВАЛИДНЫХ строк, причем жуткое время компиляции, и ооочень невысокая производительность пытаются намекнуть об обратном. Мне вообще непонятен смысл его существования, для простых вещей лучше справляется regex, для сложных — тот же бизон, позиция spirit'а мне не ясна — так ни рыба ни мясо.
Здравствуйте, Sabrian, Вы писали:
S>Мне вообще непонятен смысл его существования, для простых вещей лучше справляется regex, для сложных — тот же бизон, позиция spirit'а мне не ясна — так ни рыба ни мясо.
Он хорош в случаях динамического создания цепочек правил и динамической грамматики.
В теории практика не отличается от теории, но на практике — отличается
Здравствуйте, nau, Вы писали:
nau>Здравствуйте, Sabrian, Вы писали:
S>>Мне вообще непонятен смысл его существования, для простых вещей лучше справляется regex, для сложных — тот же бизон, позиция spirit'а мне не ясна — так ни рыба ни мясо.
nau>Он хорош в случаях динамического создания цепочек правил и динамической грамматики.
+1
Мои 5копеек:
Использование regexp, в случаях, когда с match нужно что-то ИМХО не очень удобно, спирит же, в свою очередь позволяет сразу задать соответсвующий action.
Как пример обдумайте (5 минут хватит) реализацию простого калькулятора с использованием regexp'ов, а потом гляньте, как это делается на спирите.
Вообще это конечно возможно, но потребует дикого изврата на экшенах и целой горы разных флагов, не стоит оно того. Да и не позиционируется spirit для создания парсеров чего-либо сложнее XML, это в первую очередь средство парсинга ВАЛИДНЫХ строк, причем жуткое время компиляции, и ооочень невысокая производительность пытаются намекнуть об обратном. Мне вообще непонятен смысл его существования, для простых вещей лучше справляется regex, для сложных — тот же бизон, позиция spirit'а мне не ясна — так ни рыба ни мясо.
