Есть ли инструмент командной строки для извлечения typedef, structure, enumeration, variable, function из файла C или C++?

Question

Я желаю инструмент командной строки для вывести определение или объявление (typedef, structure, enumeration, variable или function) из исходного файла C или C++. Также путем заменить было бы удобно использовать существующее определение/объявление (после преобразования извлеченного определения с помощью сценария, представленного пользователем). Существует ли такой общий инструмент или есть какое-то резонансное приближение такого инструмента?

Здесь важна возможность подключения и возможности подключения к пользовательским скриптам или программам, хотя я также академически интересуюсь программами GUI. Рекомендуются решения с открытым исходным кодом для лагеря Unix/Linux (хотя мне также интересны инструменты Windows и OS X). Первичные языковые интересы - это C и C++, но более общее решение было бы еще лучше (я думаю, нам не нужны сверхточные возможности синтаксического анализа для поиска, извлечения и замены определения в исходном файле программы).

Образец Прецеденты (за дополнительную плату - за любопытного ума):

1. Учитывая глубоко вложенным struct s и переменная (массив) инициализаций этих типов, предположим, что существует необходимость изменить определение структуры путем добавления или переупорядочения полей или переопределения определений переменных/массивов в более читаемом формате без введения ошибок, возникающих в результате ручного труда. Это будет работать, извлекая старые инициализации, а затем используя скрипт/программу для записи новых инициализаций для замены старых.
2. Для реализации инструмента просмотра кода - извлеките определение.
3. Декоративная генерация кода (например, запись/возврат записей).
4. Сценарированное структурирование кода (например, извлечение этой и той вещи и размещение в другом месте без изменений - комментарий фиксации контроля версий может документировать команду для выполнения этой операции, чтобы сделать ее очевидной и проверяемой, что ничего не изменилось).

Альтернативная проблема: Если есть инструмент сказать местоположение определения (начало и конец строки будет достаточно - мы даже могли предположить, все определения/декларации мы заинтересованы в в своей собственной линии) , то это будет односвязное осуществление ловкости пальцев, чтобы написать программу для

1. определений экстракта,
2. заменить определения, или даже

3. извлечь определение, запустить программу специфичного Fied с помощью параметров командной строки (или редактора), чтобы

   • получить желаемые извлеченные определения из stdin (или из временного файла),
   • выполнить преобразование (редактирование), и
   • вывода новых определений до stdout (или сохранить их в указанном временном файле)

   должно быть заменено исполняющей программой.

Таким образом, главная, более сложная проблема - найти начальную и конечную линии определения.

Примечание о тегах: Более точный тег, чем code-generation будет code-transformation, но она не существует.

Answer 1

Наш DMS Software Reengineering Toolkit пытается стать инструментом, который вы желаете. Но это толкает современное состояние и не является инструментом стиля нирваны. Это достаточно, чтобы делать настоящую, интересную работу.

DMS предоставляет общие возможности для синтаксического анализа, анализа и преобразования исходного кода.

Он использует явные грамматики для определения языков (таких как C и C++); грамматики управляют парсерами, которые строят абстрактные синтаксические деревья (АСТ). Различные примитивы анализа обеспечивают: а) средства [«грамматики атрибутов» ATG] для сбора информации по древовидным путям информационных потоков, которые хорошо соответствуют форме AST, b) построение использования символа для карт определения символов [«таблиц символов»] , c) control and data flow analysis с использованием фактов, извлеченных ATG, d) анализ диапазона, e) анализ точек как локального, так и глобального. Эти примитивные анализаторы могут быть использованы для составления фактов из АСТ, чтобы сделать выводы о коде, представленном АСТ (например, «это утверждение изменяет эти переменные»). A langauge front end упаковывает грамматику и анализаторы, специфичные для языка, в многоразовый пакет. DMS имеет такие языковые интерфейсы с разной степенью глубины и зрелости для самых разных языков.

[EDIT 6/27: передние концы C и C++ имеют поддержку конкретных диалектов C и C++: ANSIC, C99, GCC3/4 C, MS Visual C, ANSI C++ 98, ANSI C++ 11 , GCC3/4 C++, MS Visual C++ 2005/2008/2010. Если вам нужен точный анализ кода, вы должны использовать «правильный» диалект для обработки вашего кода.]

Но «анализ» не в этом. Цель анализа - изменить ситуацию. DMS предоставляет дополнительную поддержку процессуально модифицировать АСТ, изменять АСТ на source-to-source rewrite rules, написанные на поверхностном синтаксисе языка (оба обусловлены каким-то выбранным результатом анализа) или сгруппировать наборы процедурных и исходных переписаний вместе, чтобы сделать сложные, сложные перезаписи, которые могут переносить значительные изменения кода, такие как переструктурирование и т. д. После преобразования АСТ они могут быть использованы для регенерации («prettyprint») синтаксически правильного кода на соответствующем интерфейсе языка/диалекта. [Модифицируя АСТ для одного языка кусочно, пока у вас нет АСТ для другого, вы можете создавать переводчиков, но это не так просто, как предполагает это предложение].

Это все работает в значительной степени, но все еще несколько замешано в некоторых языковых осложнениях. Для C и C++ известным сложным является препроцессор; редактируя текст программы произвольно, условные обозначения препроцессора могут сделать исходный код невозможным для чего-либо, похожего на стандартную технологию синтаксического анализа. C DMS и передние концов C++ улучшить это несколько и могут анализировать код с хорошо структурированными директивами препроцессора, включая некоторые странные случаи, что большинство людей не называют структурированными, но которые часто встречаются:

#IF cond 
     if (abc) { 
    #ELSE 
     if (def) { 
    #ENDIF 

Мы делаем интересный прогресс в разборе коды с произвольным размещением условных препроцессоров.Но как только вы это сделаете, теперь все ваши анализаторы внезапно должны учитывать условные условия препроцессора, и мы все внезапно сталкиваемся с тем, что люди-компиляторы на самом деле не посещали.

DMS был использован для создания крупных архитектурных сдвигов в больших программах на C++, преобразовании из стиля не CORBA в стиль CORBA с огромным количеством перетасовки кода, для извлечения кода вдоль произвольных путей потока управления для создания API-интерфейсов SOW-стиля для существующий C-код, для вставки инструментов в больших программах на C для обнаружения ошибок указателя и т. д. [Он применяется к другим задачам на многих других языках].

В нашем собственном опыте это довольно сложно использовать. По нашему мнению, это в том же смысле, что демократия является наихудшей из всех систем правления, за исключением всех остальных; YMMV. На веб-сайте имеется множество инструментов и дискуссий, основанных на DMS.

Фактически он использовался для извлечения функций (SOW-упражнение является гораздо более общим, чем это) и вставляет функции (это обобщенный случай инструментария).

Такие инструменты, как GCC-XML, являются тенями возможностей DMS. GCC-XML анализирует, строит таблицы символов и дампы данные деклараций (не код), но он не может изменять какие-либо изменения кода. Кланг лучше; он анализирует C и C++ для АСТ, может анализировать промежуточное представление LLVM и имеет какой-то механизм для выплескивания к последующим исправлениям в исходный текст, вдохновленный желаемым изменением дерева. Я не знаю, сможет ли Clang выполнить массовые преобразования кода, особенно те, где результат преобразования снова преобразуется (как вы изменяете дерево для отложенного текстового патча?). DMS может делать это весь день и может делать это на многих языках, отличных от C и C++, и может делать это для произвольной смеси языков, которые он знает.

До тех пор, пока проблема препроцессора с условными выражениями не будет решена, анализ/преобразование кода на C и C++ будет непростым. Мы преуспеваем в этих задачах на этих языках только благодаря силе воли и используем самые сильные инструменты, которые мы можем построить. (Java не имеет этих проблем, и DMS соответственно лучше анализирует/преобразует его).

При серьезной опасности высокомерие я считаю, что DMS является лучшим инструментом для анализа и трансформации общего назначения. Как архитектор, я рассматриваю его как свою долгосрочную работу, чтобы сделать его еще более сильным для этой задачи.

Answer 2

Вы можете рассмотреть GCC-XML как основу для разработки инструментов, как то, о чем вы говорите. Я использовал его в сочетании с pygccxml, чтобы выполнить автоматическое извлечение глубоко вложенных элементов структуры. Это не сделает вашу работу легкой, но вам, конечно, будет лучше, чем в противном случае.

Я также слышал, как другие упоминают clang как основу для написания таких инструментов, но не имели возможности самим вглядеться в него.

Answer 3

Вы можете проверить Clang. У них есть нетривиальные библиотеки обработки исходного кода.