Существует ли лучший (более современный) инструмент, чем закон/гибкий провод для генерации токенизатора для C++?
Я недавний добавленный парсинг исходного файла к существующему инструменту, который генерировал выходные файлы от сложных параметров командной строки.
Параметры командной строки добрались, чтобы быть столь сложными, что мы начали позволять им быть предоставленными как файл, который был проанализирован, как будто это была очень большая командная строка, но синтаксис был все еще неловким. Таким образом, я добавил способность проанализировать исходный файл с помощью более разумного синтаксиса.
Я использовал гибкий провод 2.5.4, чтобы окна генерировали токенизатор для этого пользовательского формата исходного файла, и он работал. Но я ненавидел код. глобальные переменные, странное соглашение о присвоении имен и C++ кодируют сгенерированный, было ужасно. Существующий бэкенд генерации кода был склеен к выводу гибкого провода - я не использую yacc или бизона.
Я собираюсь погрузиться назад в тот код, и я хотел бы использовать лучше/больше современный инструмент. Делает любой знает чего-то это.
- Выполнения в командной строке Windows (Интеграция Visual Studio в порядке, но я использую make-файлы для создания),
- Генерирует надлежащий инкапсулированный токенизатор C++. (Никакие глобальные переменные)
- Регулярные выражения использования для описания правил маркирования (совместимый с синтаксисом закона плюс)
- Не вынуждает меня использовать c-время-выполнения (или фальсифицировать его) для чтения файла. (проанализируйте из памяти),
- Предупреждает меня, когда мои правила вынуждают токенизатор отследить в обратном порядке (или фиксирует его автоматически),
- Дает мне полный контроль над именами переменной и именами методов (таким образом, я могу соответствовать своему существующему соглашению о присвоении имен),
- Позволяет мне связывать несколько синтаксических анализаторов в единственный .exe без коллизий имени
- Может генерировать UNICODE (UCS-2 на 16 битов) синтаксический анализатор, если я хочу его к
- Не интегрированный токенизатор + парсер-генератор (я хочу замену закона, не lex+yacc замену),
Я мог, вероятно, жить с инструментом, который просто генерировал таблицы маркирования, если это было единственной доступной вещью.
5 ответов
Ragel: http://www.complang.org/ragel/ Это соответствует большинству ваших требований.
- Он работает на Windows
- , он не объявляет переменные, поэтому вы можете поместить их в класс или внутри функции, как вам нравится.
- У него есть приятные инструменты для анализа регулярных выражений, чтобы увидеть, когда они будут возвращаться. (Я не знаю об этом очень много, так как я никогда не использую синтаксис в Ragel, который создал бы багажник Backtracking.)
- Имена переменных не могут быть изменены.
- Имена таблиц префиксированы с именем машины, и они объявлены «const Static», поэтому вы можете поставить более одного в одном файле и иметь более одного с тем же именем в одной программе (до тех пор, как Они в разных файлах).
- Вы можете объявить переменные как любой целочисленный тип, включая UCAR (или любой тип UTF-16, который вы предпочитаете). Это не автоматически обрабатывает суррогатные пары. У него нет специальных классов символов для Unicode (я думаю).
- Это только регулярные выражения ... не имеет функций Bison / YACC.
Код, который он генерирует, мешает очень мало с помощью программы. Код также невероятно быстро, а синтаксис Ragel более гибкий и читаемый, чем все, что я когда-либо видел. Это каменная сплошная часть программного обеспечения. Он может генерировать анализатор, управляемый настоимостью или багажнику, управляемый Goto.
BOOST.SPIRIT и Парсер из двора прийти на мой взгляд. Обратите внимание, что подход для генераторов лексеров несколько заменен внутренним DSL DSL C ++ (языком для домена) для уточнения токенов. Просто потому, что это часть вашего кода без использования внешней утилиты, просто следуя ряд правил, чтобы указать свою грамматику.
Boost.Spirit.Qi (парсер-токенайзер) или Boost.Spirit.Lex (только токенайзер). Я абсолютно люблю Ци, и Лекс тоже неплох, но я просто склонен принимать Ци за мои потребности в синтаксическом анализе....
Единственным реальным недостатком Qi, как правило, является увеличение времени компиляции, а также он работает немного медленнее, чем написанный от руки парсинговый код. Однако, в целом, он работает намного быстрее, чем при разборе с помощью регекса.
http://www.boost.org/doc/libs/1_41_0/libs/spirit/doc/html/index.html
Flex также имеет опцию выхода C++.
В результате получается набор классов, которые делают такой разбор.
Просто добавьте в заголовок своего лексического файла:
%option C++
%option yyclass="Lexer"
Затем в исходные тексты:
std::fstream file("config");
Lexer lexer(&file)
while(int token = lexer.yylex())
{
}
Есть два инструмента, которые приступают к уму, хотя вам нужно будет выяснить для себя, что будет подходящим, ANTLR и GoldParser . Есть языковые привязки, доступные в обоих инструментах, в которых он может быть подключен к среде выполнения C ++.