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

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

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

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

Ответы

Ответ 1

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

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

Ответ 3

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

Моя стратегия такова:

(1) Если A.h, где объявлен класс A, относится к классу B, то   Я должен включить заголовок B.h.   Если объявление класса А содержит только тип * B, тогда мне нужно только   форвардная декларация класса B; в A.h. Мне может потребоваться включить B.h в A.cpp

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

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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