Виявлення зайвих # включень в C / C ++?

Я часто виявляю, що розділ заголовків файлу постійно стає більшим і більшим, але він ніколи не стає меншим. Протягом життя класів вихідних файлів, можливо, були перенесені та відремонтовані, і дуже можливо, що існує досить багато таких, #includesяким не потрібно бути там і більше. Залишаючи їх там лише продовжують час компіляції та додають зайві залежності від компіляції. Спроба з'ясувати, які ще потрібні, може бути досить стомлюючою.

Чи є якийсь інструмент, який може виявити зайві директиви #include та підказати, які з них я можу безпечно видалити?
Чи може це робити линзи?

Це не автоматично, але доксиген створює діаграми залежності для #includedфайлів. Вам доведеться пройти через них візуально, але вони можуть бути дуже корисними для отримання уявлення про те, що використовується для чого.

Google cppclean (посилання на: завантаження , документацію ) може знайти кілька категорій проблем C ++, і тепер він може знайти зайві #includes.

Існує також інструмент на базі Кланг, включте- що-ви використовуєте , який може це зробити. include-what-you-use може навіть запропонувати декларації вперед (тому вам не доведеться #include так багато) та необов'язково очистити #includes для вас.

Поточні версії Eclipse CDT також вбудовані в цю функціональність: перейшовши в меню "Джерело" та натиснувши "Впорядкувати включено", ви будете алфавітувати ваші # включення, додавати заголовки, які Eclipse вважає, що ви використовуєте, не включаючи їх безпосередньо, та коментувати будь-які заголовки, які не мають я не думаю, що потрібно. Однак ця функція не є на 100% надійною.

Також ознайомтеся з функцією "включити-що-ви-використовувати" , що вирішує подібну проблему.

Проблема з виявленням зайвого включає те, що воно не може бути просто перевіряючою залежністю типу. Не зайвим є файл, який не забезпечує нічого компіляційному і не змінює інший елемент, від якого залежать інші файли. Існує багато способів, як заголовок-файл може змінити компіляцію, скажімо, визначивши константу, переосмисливши та / або видаливши використаний макрос, додавши простір імен, який певним чином змінює пошук імені. Для виявлення таких елементів, як простір імен, вам потрібно набагато більше, ніж препроцесору, вам фактично майже потрібен повний компілятор.

Lint - це більше перевірка стилю, і, звичайно, не матиме такої повної можливості.

Я думаю, що ви знайдете єдиний спосіб виявити зайву функцію - це видалити, компілювати та запустити набори.

Я думав, що PCLint зробить це, але минуло кілька років, як я це переглянув. Ви можете це перевірити.

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

CScout рефакторінга браузер може виявити зайве включати директиви в C ( до жаль , НЕ C ++) коду. Опис того, як це працює, ви можете знайти в цій статті журналу.

Ви можете написати швидкий скрипт, який стирає єдину директиву #include, компілює проекти та записує ім'я в #include та файл, з якого було видалено, якщо помилок компіляції не сталося.

Нехай воно працює протягом ночі, а наступного дня у вас буде 100% правильний список файлів, що включають файли, які ви можете видалити.

Іноді груба сила просто працює :-)

редагувати: а іноді це не так :-). Ось трохи інформації з коментарів:

1. Іноді ви можете видалити два файли заголовка окремо, але не обидва разом. Рішення - видалити файли заголовків під час запуску, а не повертати їх назад. Тут знайдеться список файлів, які ви можете безпечно видалити, хоча може бути рішення з більшою кількістю файлів, видалити які цей алгоритм не знайде. (це жадібний пошук по простору включених файлів, які потрібно видалити. Він знайде лише локальний максимум)
2. Можливі незначні зміни в поведінці, якщо у вас є деякі макроси, переосмислені по-різному, залежно від деяких #ifdefs. Я думаю, що це дуже рідкісні випадки, і Тестові модулі, які є частиною збірки, повинні сприймати ці зміни.

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

Перевірте мій коментар до crashmstr, FlexeLint / PC-Lint зробить це за вас. Інформаційне повідомлення 766. Розділ 11.8.1 мого посібника (версія 8.0) обговорює це.

Крім того, і це важливо, продовжуйте повторювати, поки повідомлення не зникне . Іншими словами, після видалення невикористаних заголовків, повторного запуску вказівника, після видалення деяких непотрібних заголовків, можливо, більше заголовкових файлів можуть стати "непотрібними". (Це може звучати нерозумно, читайте його повільно і аналізуйте, це має сенс.)

Я ніколи не знайшов повноцінного інструменту, який би виконав те, що ви просите. Найближче, що я використав, - 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 ++ з блогу Ігри зсередини. Вони рекомендують комплексний підхід до очищення безладу #include:

Керівні принципи

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

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

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

У цій статті пояснюється техніка видалення #include за допомогою аналізу синтаксису Doxygen. Це просто сценарій perl, тому він досить простий у використанні.

Можливо, трохи пізно, але я одного разу знайшов сценарій perl WebKit, який робив саме те, що ви хотіли. Я потребую певної адаптації, я вважаю (я не дуже добре розбираюся в perl), але він повинен зробити трюк:

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

(це стара гілка, оскільки в магістралі більше немає файлу)

Є безкоштовний інструмент " Включити диспетчер файлових залежностей", який можна інтегрувати у візуальну студію. Він показує зайві # включено червоним кольором.

Існує два типи зайвих файлів #include:

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

На моєму досвіді є два способи, які добре виявляють це:

• gcc -H або cl.exe / showincludes (вирішити проблему 2)

  У реальному світі ви можете експортувати CFLAGS = -H перед внесенням, якщо всі Makefile не перекривають параметри CFLAGS. Або, як я використав, ви можете створити обгортку cc / g ++, щоб примусово додавати параметри -H до кожного виклику $ (CC) та $ (CXX). і додайте до папки обгортки змінну $ PATH, тоді ваша марка використовує замість вас команду обгортки. Звичайно, ваша обгортка повинна викликати справжній компілятор gcc. Ці трюки потрібно змінити, якщо ваш Makefile використовує gcc безпосередньо. замість $ (CC) або $ (CXX) або за маючи на увазі правила.

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

  очистити

  скласти 2> & 1 | tee результат.txt

• PC-Lint / FlexeLint (вирішити проблему як 1, так і 2)

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

  pclint / flint -vf ...

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

Закінчивши це обговорення: препроцесор c ++ закінчується. Це смислова властивість, незалежно від того, включити включення. Звідси випливає з теореми Райса, що не можна визначити, зайвим є чи включати. НЕ МОЖЕ бути програми, яка (завжди правильно) визначає, чи не включити включення.

Ось простий спосіб ідентифікації зайвих заголовків . Це не ідеально, але виключає "очевидні" зайві включає. Позбавлення від них проходить чималий шлях в очищенні коду.

До скриптів можна отримати доступ безпосередньо на GitHub.

PC Lint Gimpel Software може звітувати про те, коли файл компіляції не один раз включався в компіляційний блок , але він не може знайти включені файли, які не потрібні способом, який ви шукаєте.

Редагувати: Це може. Дивіться відповідь їїматта

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

Я виявив, що ви платите за цю функціональність; CLion потребує певного часу, щоб сканувати та аналізувати проект при першому завантаженні.