Самый эффективный способ анализа C-подобных строк определений?

Question

У меня есть набор определений функций, написанных на C-подобном языке, с некоторыми дополнительными ключевыми словами, которые можно поставить перед некоторыми аргументами (например, «unsigned» или «register»), и мне нужно проанализируйте эти строки, а также некоторые заглушки функций и сгенерируйте из них реальный код C.

• Верно ли, что Flex / Yacc - самый правильный способ сделать это?

• Будет ли это медленнее, чем написание сценария Shell или Python с использованием регулярных выражений (что может стать большой болью, как я полагаю, если количество дополнительных ключевых слов станет больше и их эффекты будут довольно разными) при условии, что у меня есть ноль опыта работы с анализаторами / парсерами (хотя я знаю, как LALR выполняет свою работу)?

• Есть ли какие-нибудь хорошие материалы на Lex / Yacc, которые освещают подобные проблемы? Все бумаги, которые я смог найти, используют один и тот же примитивный пример «игрушечного» калькулятора.

Любая помощь будет оценена.

Answer 1

Существует также Лимонный парсер , который имеет менее строгую грамматику. Недостатком является то, что вы женаты на лимоне, переписываете грамматику парсера на что-то другое, когда обнаруживаете какое-то отстой. Положительным моментом является то, что он действительно прост в использовании ... и самодостаточен. Вы можете бросить его в дерево и не беспокоиться о проверке на наличие других.

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

Answer 2

ANTLR обычно используется (как и Lex \ Yacc).

ANTLR, еще один инструмент для языка Признание, это языковой инструмент, который обеспечивает основу для построения распознаватели, переводчики, компиляторы, и переводчики с грамматического описания, содержащие действия в разнообразие целевых языков.

Answer 3

на самом деле, это зависит от того, насколько сложен ваш язык и действительно ли он близок к С или нет ...

Тем не менее, вы можете использовать lex в качестве первого шага даже для регулярного выражения ....

Я бы пошел на Лекса + Менгира и О'Камла ....

но любая комбинация flex / yacc будет в порядке ..

Основная проблема с обычным бизоном (реализация yacc для gnu) связана с типизацией Си ... вам нужно описать все дерево (и все функции манипуляции) ... Использовать o'caml было бы действительно проще .. .

Answer 4

Это полностью зависит от вашего определения «эффективный». Если у вас есть все время в мире, самый быстрый парсер будет рукописный парсер. На их отладку и разработку уходит много времени, но сегодня ни один генератор синтаксических анализаторов не сравнится с рукописным кодом с точки зрения производительности во время выполнения.

Если вы хотите что-то, что может анализировать действительный C в течение недели или около того, используйте генератор синтаксического анализатора. Код будет достаточно быстрым, и большинство генераторов парсеров уже имеют грамматику для C, которую вы можете использовать в качестве отправной точки (избегая 90% распространенных ошибок).

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

Answer 5

Для того, что вы хотите сделать, наш DMS Software Reengineering Toolkit , вероятно, является очень эффективным решением.

DMS разработан специально для поддержки анализаторов / генераторов кода того типа, который вы обсуждаете. Он предоставляет очень мощные средства для определения произвольных языковых синтаксических анализаторов / анализаторов (протестировано на более чем 30 реальных языках, включая несколько полных диалектов C, C ++, Java, C # и COBOL).

DMS автоматизирует построение AST (так что вам не нужно ничего делать, а получить правильную грамматику, чтобы иметь пригодный для использования AST), позволяет создавать пользовательские анализы именно указанной вами инспекции, ориентированной на шаблоны, и создавать новые Специфичные для C AST, представляющие код, который вы хотите сгенерировать, и выкладываемые в виде скомпилированного исходного текста на C. Существующие ранее определения C для DMS, вероятно, могут быть изогнуты, чтобы охватить ваш C-подобный язык.