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

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

Есть ли какой-нибудь инструмент, который может обнаружить лишние директивы #include и предложить, какие из них я могу безопасно удалить?
Может ли это сделать Линт?

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

Google cppclean (ссылки на: скачать , документация ) может найти несколько категорий проблем C ++, и теперь он может найти лишние #include.

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

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

Также проверьте include-what-you-use , который решает похожую проблему.

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

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

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

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

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

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

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

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

Иногда грубой силы просто работает :-)

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

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

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

Посмотрите мой комментарий к 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. Есть больше патологических случаев, но в основном вам нужно будет самостоятельно проверить заголовки для достижения наилучших результатов.

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

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

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

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

Если вы используете Eclipse CDT, вы можете попробовать http://includator.com, который является бесплатным для бета-тестеров (на момент написания этой статьи) и автоматически удаляет лишние #include или добавляет отсутствующие. Для тех пользователей, которые имеют 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 красным.

Существует два типа лишних файлов #include:

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

В моем опыте есть 2 способа, которые хорошо подходят для его обнаружения:

• gcc -H или cl.exe / showinclude (решить проблему 2)

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

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

  очистить

  сделать 2> & 1 | tee result.txt

• PC-Lint / FlexeLint (решить проблему 1 и 2)

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

  pclint / flint -vf ...

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

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

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

В сценарии могут быть доступны непосредственно на GitHub.

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

Редактировать: это может. См ответ егоmatt

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

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