Существуют ли инструменты, которые помогают организовать #include?

Question

Существуют ли какие-либо инструменты, помогающие организовать #include s, которые находятся в начале файла .c или .h?

Мне было просто интересно, потому что я реорганизую свой код, перемещая различные маленькие определения / объявления функций из одного длинного файла в разные меньшие файлы.Теперь каждому из меньших файлов требуется подмножество #include s, которые были в верхней части длинного файла.

Просто раздражает и подвержен ошибкам, чтобы выяснить все #include вручную.Часто код компилируется, хотя не все #include есть.Пример: Файл A широко использует std::vector, но не включает vector;но в настоящее время он включает какой-то непонятный другой заголовок, который включает vector (может быть, через некоторые рекурсивные включения).

Answer 1

VisualAssistX может помочь вам перейти к определению типа.Например, если вы используете класс MyClass в своем источнике, вы можете щелкнуть по нему, выбрать Goto Definition, и VisualAssistX откроет включаемый файл, содержащий определение этого класса (возможно, Visual Studio также может сделать это, но в этот момент я так привыкаюдля VisualAssistX, что я добавляю каждую замечательную функцию в VisualAssistX :-)).Вы можете использовать это, чтобы найти включаемый файл, необходимый для вашего исходного кода.

PC-Lint может сделать с точностью до наоборот.Если у вас есть включаемый файл в вашем источнике, который не используется, PC-Lint может предупредить вас об этом, чтобы вы знали, что включаемый файл может быть удален из источника (что окажет положительное влияние на время вашей компиляции).

Answer 2

Now each of the smaller files needs a subset of the #includes that were at the top of the long file.

Я делаю это с помощью VisualAssistX.Сначала скомпилируйте файл, чтобы увидеть, чего не хватает.Затем вы можете использовать функцию добавления включения VisualAssistX.Поэтому я просто щелкаю правой кнопкой мыши по функциям или классам, которые, как я знаю, нуждаются во включении, и нажимаю «Добавить включение».Перекомпилируйте пару раз, чтобы отфильтровать новые пропущенные включения, и все готово.Надеюсь, я написал это по понятным причинам:)

Не идеально, но быстрее, чем делать это вручную.

Answer 3

Так как этот вопрос был задан, был создан новый инструмент: include-what-you-use , он основан на clang, предоставляет сопоставления для имитации существования определенных символов memory, но на самом деле определено в bits/unique_ptr.h в некоторых стандартных заголовках и позволяет вам предоставлять собственные сопоставления.

Обеспечивает хорошую диагностику и автоматическое переписывание.

Answer 4

Я занимался этой проблемой в последнее время.В нашем проекте мы используем C ++ и имеем один Xh и один файл X.cpp для каждого класса X.

Моя стратегия следующая:

(1) Если Ah, где объявлен класс A, относится к классу B, тогда я должен включить заголовок Bh. Если объявление класса A содержит только тип * B, то мне нужно только предварительное объявление class B; в Ah, возможно, мне потребуется включитьBh в A.cpp

(2) Используя вышеописанную процедуру, я перемещаю как можно больше включений из Ah в A.cpp.Затем я пытаюсь удалить одно включение за раз и посмотреть, компилируется ли файл .cpp.Это должно позволить минимизировать набор включаемых файлов в файле .cpp, но я не уверен на 100%, если результат минимален.Я также думаю, что можно написать инструмент, который сделает это автоматически.Я начал писать один для Visual Studio.Я был бы рад узнать, что есть такие инструменты.

Примечание : возможно, добавление правильной конструкции модуля с четко определенными отношениями импорта / экспорта может быть желательным дополнением для C ++ 0x,Это значительно упростит задачу реорганизации импорта и значительно ускорит компиляцию.

Answer 5

makedepend и gccmakedep

Answer 6

Я использую графики, сгенерированные doxygen / dot-graphviz, чтобы увидеть, как связаны файлы. Очень удобно, но не автоматически, вам нужно визуально проверять графики, а затем редактировать код, чтобы удалить ненужные строки "#include" Конечно, не очень подходит для очень больших проектов (скажем,> 100 файлов), где графики становятся непригодными для использования.