Обнаружение лишних #includes в C / C ++?

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

Cppclean от Google (ссылки на: загрузить, documentation) может найти несколько категорий проблем C ++, а теперь может найти лишние #includes.

Также существует инструмент на основе Clang, include-what-you-use, которые могут это сделать. include-what-you-use может даже предлагать форвардные объявления (так что вам не нужно так много #include) и, при необходимости, очищать ваши #includes за вас.

В текущих версиях Eclipse CDT также встроена эта функция: переход в меню «Источник» и нажатие «Организовать включает» приведет к расположите в алфавитном порядке ваши # include, добавьте любые заголовки, которые, по мнению Eclipse, вы используете, не включая их напрямую, и закомментируйте любые заголовки, которые, по его мнению, вам не нужны. Однако эта функция не на 100% надежна.

Также ознакомьтесь с include -what-you-use, который решает аналогичную проблему.

Проблема с обнаружением лишних включений заключается в том, что это не может быть просто средство проверки зависимостей типов. Излишнее включение - это файл, который ничего не представляет для компиляции и не изменяет другой элемент, от которого зависят другие файлы. Есть много способов, которыми файл заголовка может изменить компиляцию, например, путем определения константы, переопределения и / или удаления используемого макроса, добавления пространства имен, которое изменяет поиск имени в некоторой степени вниз по строке. Для обнаружения таких элементов, как пространство имен, вам нужно гораздо больше, чем препроцессор, вам фактически почти нужен полноценный компилятор.

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

Я думаю, вы найдете единственный способ обнаружить лишнее включение - это удалить, скомпилировать и запустить наборы.

Я думал, что PCLint сделает это, но прошло несколько лет с тех пор, как я посмотрел на это. Вы можете это проверить.

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

Браузер с рефакторингом CScout может обнаруживать лишние директивы include в коде C (к сожалению, не C ++). Вы можете найти описание того, как это работает, в этой журнальной статье.

Вы можете написать быстрый сценарий, который стирает одну директиву #include, компилирует проекты и регистрирует имя в #include и файл, из которого он был удален, в случае, если ошибок компиляции не произошло.

Дайте ему поработать на ночь, и на следующий день у вас будет 100% правильный список включаемых файлов, которые вы можете удалить.

Иногда просто срабатывает брутфорс :-)

изменить: а иногда нет :-). Вот немного информации из комментариев:

1. Иногда можно удалить два файла заголовков по отдельности, но не оба вместе. Решение состоит в том, чтобы удалить файлы заголовков во время выполнения и не возвращать их. Будет найден список файлов, которые вы можете безопасно удалить, хотя может быть решение с большим количеством файлов для удаления, которые этот алгоритм не найдет. (это жадный поиск по пространству включаемых файлов для удаления. Будет найден только локальный максимум)
2. В поведении могут быть небольшие изменения, если некоторые макросы переопределены по-разному в зависимости от некоторых #ifdef. Я думаю, что это очень редкие случаи, и модульные тесты, которые являются частью сборки, должны улавливать эти изменения.

Извините за (повторно) публикацию здесь, люди часто не расширяют комментарии.

Прочтите мой комментарий к crashmstr, FlexeLint / PC-Lint сделает это за вас. Информационное сообщение 766. Это обсуждается в разделе 11.8.1 моего руководства (версия 8.0).

Кроме того, и это важно, продолжайте повторять, пока сообщение не исчезнет. Другими словами, после удаления неиспользуемых заголовков и повторного запуска lint дополнительные файлы заголовков могут стать «ненужными» после удаления некоторых ненужных заголовков. (Это может показаться глупым, прочтите это медленно и проанализируйте, это имеет смысл.)

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

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

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

Один из способов, которым автоматизированные инструменты могут ошибиться:

В A.hpp:

class A { 
  // ...
};

В B.hpp:

#include "A.hpp

class B {
    public:
        A foo;
};

В C.cpp:

#include "C.hpp"  

#include "B.hpp"  // <-- Unneeded, but lint reports it as needed
#include "A.hpp"  // <-- Needed, but lint reports it as unneeded

Если вы слепо следите за сообщениями Flexelint, вы испортите свои #include зависимости. Есть и другие патологические случаи, но в основном вам нужно будет проверить заголовки самостоятельно для достижения наилучших результатов.

Я настоятельно рекомендую эту статью о Physical Structure и C ++ из блога Games изнутри. Они рекомендуют комплексный подход к устранению беспорядка #include:

Руководящие указания

Вот обобщенный набор рекомендаций из книги Лакоса, которые минимизируют количество физических зависимостей между файлами. Я использую их в течение многих лет и всегда был очень доволен результатами.

1. Каждый файл cpp сначала включает собственный файл заголовка. [отрывок]
2. Заголовочный файл должен включать все заголовочные файлы, необходимые для его анализа. [отрывок]
3. Заголовочный файл должен иметь минимальное количество заголовочных файлов, необходимое для его анализа. [отрывок]

Если вы используете Eclipse CDT, вы можете попробовать http://includator.com, который бесплатен для бета-тестеров (во время это письмо) и автоматически удаляет лишние #includes или добавляет недостающие. Для тех пользователей, у которых есть FlexeLint или PC-Lint и которые используют Elicpse CDT, вариантом может быть http://linticator.com. (также бесплатно для бета-тестирования). Хотя он использует анализ Lint, он предоставляет быстрые исправления для автоматического удаления лишних операторов #include.

В этой статье объясняется техника удаления #include с помощью синтаксического анализа Doxygen. Это просто Perl-скрипт, поэтому пользоваться им довольно просто.

Может быть, немного поздно, но однажды я нашел Perl-скрипт WebKit, который делал именно то, что вы хотели. Думаю, потребуется некоторая адаптация (я плохо разбираюсь в perl), но это должно помочь:

http://trac.webkit.org/browser/branches/old/safari-3-2-branch/WebKitTools/Scripts/find-extra-includes

(это старая ветка, потому что в стволе больше нет файла)

Существует бесплатный инструмент Include File Dependencies Watcher, который можно интегрировать в визуальную студию. Он показывает лишние #includes красным.

Есть два типа лишних файлов #include:

1. Заголовочный файл, который модулю вообще не нужен (.c, .cpp)
2. Заголовочный файл необходим модулю, но он включается более одного раза, прямо или косвенно.

По моему опыту, есть два способа его обнаружения:

• gcc -H или cl.exe / showincludes (решение проблемы 2)

  В реальном мире вы можете экспортировать CFLAGS = -H перед make, если все параметры Makefile не отменяют параметры CFLAGS. Или, как я использовал, вы можете создать оболочку cc / g ++ для принудительного добавления параметров -H к каждому вызову $ (CC) и $ (CXX). и добавьте каталог оболочки к переменной $ PATH, тогда ваша программа make будет использовать вместо нее вашу команду оболочки. Конечно, ваша оболочка должна вызывать настоящий компилятор gcc. Эти приемы необходимо изменить, если ваш Makefile напрямую использует gcc. вместо $ (CC) или $ (CXX) или подразумеваемыми правилами.

  Вы также можете скомпилировать отдельный файл, настроив его в командной строке. Но если вы хотите очистить заголовки для всего проекта. Вы можете захватить весь вывод с помощью:

  очистить

  сделать 2> & 1 | тройник result.txt

• PC-Lint / FlexeLint (решение проблемы как 1, так и 2)

  обязательно добавьте параметры + e766, это предупреждение касается неиспользуемых файлов заголовков.

  pclint / flint -vf ...

  Это приведет к тому, что pclint выведет включенные файлы заголовков, вложенные файлы заголовков будут иметь соответствующий отступ.

CLion, IDE C / C ++ от JetBrains, сразу же обнаруживает избыточные включения. Они неактивны в редакторе, но есть также функции для оптимизации включает в текущий файл или весь проект.

Я обнаружил, что вы платите за эту функцию; CLion требуется время для сканирования и анализа вашего проекта при первой загрузке.

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

Доступ к скриптам можно получить непосредственно на GitHub.

PC Lint от Gimpel Software может сообщать, когда включаемый файл был включен более одного раза в модуль компиляции , но он не может найти включаемые файлы, которые не нужны вам так, как вы ищете.

Изменить: Может. См. ответ itsmatt

В заключение: препроцессор C ++ завершен по Тьюрингу. Является ли включение лишним - это семантическое свойство. Следовательно, из теоремы Райса следует, что неразрешимо, является ли включение лишним или нет. НЕ МОЖЕТ быть программа, которая (всегда правильно) определяет, является ли включение лишним.