Зачем использовать названия «Дух», «Ци» и «Карма»? Потому что кспрессивные имена имеют лучший дух, привносят ци в ваше программное обеспечение и усиливают вашу карму, чтобы они могли исцелить ваше слияние и заставить вас махать, как феникс из пепла. (Иоахим Фульхабер)
Правила пересекают границу между статичным и динамическим C++. По сути, правило трансформирует полиморфизм времени компиляции (используя шаблоны) в полиморфизм времени выполнения (используя виртуальные функции). Это необходимо из-за неспособности C++ автоматически объявить переменную типа, выведенную из произвольно сложного выражения в правой стороне (rhs) задания. В принципе, мы хотим сделать что-то вроде:
T rule = an_arbitrarily_complex_expression;
без необходимости знать или заботиться о результирующем типе правой стороны выражения назначения. Это можно сделать с помощью современных компиляторов C++ 0x, используя auto:
auto rule = an_arbitrarily_complex_expression;
Кроме того, нам также нужен объект для декларирования неизвестного типа:
T rule;
...
rule = a | b;
Эти ограничения ведут нас к реализации правил. Это происходит за счет накладных расходов на стертый типом вызов, который является косвенным вызовом функции, который не должен быть включен, один раз через каждое вызов правила.
Некоторые варианты BNF допускают несколько деклараций правила. Заявления принимаются в качестве альтернативы. Пример:
r = a;
r = b;
эквивалентны:
r = a | b;
Дух 1.3 допускает такое поведение. Однако нынешняя версия Spirit больше не допускает этого, потому что опыт показывает, что такое поведение приводит к нежелательным готчам (например, не позволяет держать правила в контейнерах). При нынешнем освобождении Духа второе назначение правилу просто переопределит его. Старое определение разрушается. Это следует за семантикой C++ и больше соответствует тому, что пользователь ожидает от правила.
Оператор запятой, как в a, b, кажется, лучше кандидат, синтаксис-мудрый. Но проблема заключается в его приоритете. Он имеет самый низкий приоритет в C/C++, что делает его практически бесполезным.
Бьярн Страуструп в своей статье «Обобщение перегрузки для C++2000» рассказывает о перегрузке белого пространства. Такая функция позволила бы сопоставлять парсерные объекты точно так же, как мы делаем в (E)BNF (например, a b | c вместо a > > b | c). К сожалению, статья датирована 1 апреля 1998 года. Хорошо.
В общем, ожидаемый итератор является, по меньшей мере, стандартным, соответствующим переднему итератору. Форвардные итераторы необходимы для обратного отсчета, где итератор должен быть сохранен и восстановлен позже. Вообще говоря, Spirit является парсером обратного пути. Смысл этого заключается в том, что в какой-то момент положение итератора должно быть сохранено, чтобы позволить парсеру вернуться к предыдущей точке. Таким образом, для обратного перехода к работе фреймворк требует, по крайней мере, переднего итератора.
Конечно, есть средства правовой защиты. В тех случаях, когда нам нужно использовать итераторы ввода, вы можете использовать итератор multi_pass для создания итераторов вперед.
Некоторым парсерам могут потребоваться более специализированные итераторы (двунаправленный или даже случайный доступ). Возможно, в будущем детерминированные парсеры при добавлении в фреймворк не будут выполнять обратную связь и потребуют только один токен, следовательно, потребуют только итераторы ввода.
Дух не делает исчерпывающее отступление, как ожидают регулярные выражения. Например:
*char_('a') >> char_('a');
звезда Духа Клин не отступает, когда остальные правила не совпадают.
На самом деле, есть решение этой жадной проблемы РД. Такая схема обсуждается в разделе 6.6.2 Методы парсинга: Практическое руководство. Хитрость заключается в передаче хвостового парсера (в дополнение к сканеру) каждому парсеру. Тогда стартовым парсером будет просто:
start >> end;
(конец — это хвост старта).
Дух жадный, используя прямо вперед, наивный РД. Конечно, можно реализовать полностью схему обратного отслеживания, представленную выше, но также будет хит производительности. Схема всегда будет пытаться сопоставить все возможные пути парсера (полный обход иерархии парсера) до тех пор, пока не достигнет точки уверенности, что все совпадает или не совпадает.
Скриншоты и Greedy RD
Дух довольно постоянен и интуитивно понятен в том, когда он возвращается и куда, хотя это может быть не очевидно для тех, кто приходит из разных слоев общества. Как правило, любой (под)парсер, учитывая один и тот же вход, всегда соответствует одной и той же части входа (или вообще не соответствует входу). Это означает, что Дух по своей природе жадный. Дух будет отступать только тогда, когда (под)парсер не соответствует входу, и он всегда будет отступать к следующей точке выбора вверх (а не назад) в структуре парсера. Другими словами, abb |ab будет соответствовать "ab", как и a |b) |ab)b |2>a после 'a', если он доступен.
Райнер Дейк
Это и есть суть грамматики выражения Парсинга .
Существует сильное предпочтение подходу «простота со всеми ручками, когда они вам нужны». С другой стороны, гибкость Духа позволяет иметь различные факультативные схемы. Возможно, в будущем можно будет реализовать исчерпывающую схему обратного отслеживания РД в качестве дополнительной функции.
