Wykrywanie zbędnego # zawiera w C / C ++?

Często stwierdzam, że sekcja nagłówków pliku stale się powiększa, ale nigdy się nie zmniejsza. Przez cały okres istnienia pliku źródłowego klasy mogły się przenosić i były refaktoryzowane, i jest bardzo możliwe, że istnieje wiele takich #includes, które nie muszą już tam być. Pozostawienie ich tam tylko przedłuża czas kompilacji i dodaje niepotrzebne zależności kompilacji. Próba ustalenia, które są nadal potrzebne, może być dość nużąca.

Czy istnieje jakieś narzędzie, które może wykrywać zbędne dyrektywy #include i sugerować, które mogę bezpiecznie usunąć?
Czy może to robić?

Nie jest to automatyczne, ale doxygen wytworzy diagramy zależności dla #includedplików. Będziesz musiał przejrzeć je wizualnie, ale mogą one być bardzo przydatne do uzyskania obrazu tego, czego używa.

Google cppclean (linki do: pobierania , dokumentacji ) może znaleźć kilka kategorii problemów w C ++, a teraz może znaleźć zbędne #includes.

Istnieje również narzędzie oparte na Clang, które zawiera to, czego używasz , które może to zrobić. include-what-you-use może nawet sugerować przekazywanie deklaracji (więc nie musisz #include tak dużo) i opcjonalnie wyczyść #include dla ciebie.

Obecne wersje Eclipse CDT mają również wbudowaną tę funkcję: przejście do menu Źródło i kliknięcie opcji Organizuj dołączenia spowoduje alfabetyczność twoich # włączników, doda wszystkie nagłówki, które według Eclipse są używane bez ich bezpośredniego uwzględnienia, i skomentuje wszystkie nagłówki, których nie robi nie sądzę, że potrzebujesz. Ta funkcja nie jest jednak w 100% niezawodna.

Sprawdź także opcję „włącz to, czego używasz” , która rozwiązuje podobny problem.

Problem z wykrywaniem zbędnych treści polega na tym, że nie może to być tylko sprawdzanie zależności typu. Zbędne dołączanie to plik, który nie zapewnia nic wartościowego w kompilacji i nie zmienia innego elementu, od którego zależą inne pliki. Plik nagłówka może zmienić kompilację na wiele sposobów, na przykład poprzez zdefiniowanie stałej, ponowne zdefiniowanie i / lub usunięcie używanego makra, dodanie przestrzeni nazw, która zmienia sposób wyszukiwania nazwy w pewnym stopniu wzdłuż linii. Aby wykryć elementy takie jak przestrzeń nazw, potrzebujesz znacznie więcej niż preprocesora, w rzeczywistości potrzebujesz prawie pełnego kompilatora.

Lint jest raczej sprawdzianem stylu i na pewno nie będzie miał takich możliwości.

Myślę, że jedynym sposobem na wykrycie zbędnego włączenia jest usunięcie, kompilacja i uruchomienie pakietów.

Myślałem, że PCLint to zrobi, ale minęło kilka lat, odkąd na to spojrzałem. Możesz to sprawdzić.

Spojrzałem na tego bloga, a autor mówił trochę o konfigurowaniu PCLint, aby znaleźć nieużywane załączniki. Może warto rzucić na to okiem.

CScout przeglądarka refaktoring może wykryć zbędny obejmują dyrektyw w C (niestety nie C ++) kodu. Opis tego, jak to działa, można znaleźć w tym artykule w czasopiśmie.

Możesz napisać szybki skrypt, który usuwa pojedynczą dyrektywę #include, kompiluje projekty i zapisuje nazwę w #include oraz plik, z którego został usunięty, na wypadek, gdyby nie wystąpiły błędy kompilacji.

Niech uruchomi się w nocy, a następnego dnia będziesz mieć 100% poprawną listę plików dołączanych, które możesz usunąć.

Czasami brutalna siła po prostu działa :-)

edycja: a czasami nie :-). Oto trochę informacji z komentarzy:

1. Czasami możesz usunąć dwa pliki nagłówka osobno, ale nie oba jednocześnie. Rozwiązaniem jest usunięcie plików nagłówkowych podczas uruchamiania i nie przywracanie ich. Znajduje się tutaj lista plików, które można bezpiecznie usunąć, chociaż może istnieć rozwiązanie z większą liczbą plików do usunięcia, których ten algorytm nie znajdzie. (jest to chciwe wyszukiwanie w obszarze plików dołączanych do usunięcia. Znajduje tylko lokalne maksimum)
2. Mogą wystąpić subtelne zmiany w zachowaniu, jeśli niektóre makra zostaną zdefiniowane inaczej w zależności od niektórych #ifdefs. Myślę, że są to bardzo rzadkie przypadki, a testy jednostkowe, które są częścią kompilacji, powinny wychwycić te zmiany.

Przykro mi, że (ponownie) publikuję tutaj, ludzie często nie rozwijają komentarzy.

Sprawdź mój komentarz do crashmstr, FlexeLint / PC-Lint zrobi to za Ciebie. Komunikat informacyjny 766. Sekcja 11.8.1 mojej instrukcji (wersja 8.0) omawia to.

Jest to również ważne i powtarzaj, dopóki komunikat nie zniknie . Innymi słowy, po usunięciu nieużywanych nagłówków, uruchom ponownie włókna, więcej plików nagłówków może stać się „niepotrzebnych” po usunięciu niektórych niepotrzebnych nagłówków. (Może to zabrzmieć głupio, przeczytaj go powoli i przeanalizuj, ma to sens).

Nigdy nie znalazłem pełnoprawnego narzędzia, które spełni Twoje oczekiwania. Najbliższą rzeczą, której użyłem, jest IncludeManager , który przedstawia wykres drzewa włączenia nagłówka, dzięki czemu można wizualnie dostrzec takie rzeczy, jak nagłówki zawarte tylko w jednym pliku i okrągłe włączenia nagłówków.

Próbowałem użyć Flexelint (uniksowa wersja PC-Lint) i uzyskałem nieco mieszane wyniki. Jest to prawdopodobne, ponieważ pracuję na bardzo dużej i zawiłej bazie kodu. Zalecam uważne sprawdzenie każdego pliku zgłoszonego jako nieużywany.

Głównym zmartwieniem są fałszywe alarmy. Wiele włączeń tego samego nagłówka jest zgłaszanych jako niepotrzebny nagłówek. Jest to złe, ponieważ Flexelint nie mówi ci, w którym wierszu jest zawarty nagłówek ani gdzie był zawarty wcześniej.

Jeden ze sposobów, w jaki zautomatyzowane narzędzia mogą to zrobić źle:

W A.hpp:

class A { 
  // ...
};

W B.hpp:

#include "A.hpp

class B {
    public:
        A foo;
};

W 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

Jeśli ślepo podążasz za wiadomościami od Flexelint, zepsujesz swoje zależności #include. Jest więcej przypadków patologicznych, ale w zasadzie będziesz musiał sam sprawdzić nagłówki, aby uzyskać najlepsze wyniki.

Bardzo polecam ten artykuł na temat struktury fizycznej i C ++ z blogu Games od wewnątrz. Zalecają kompleksowe podejście do usuwania bałaganu #include:

Wytyczne

Oto destylowany zestaw wytycznych z książki Lakos, które minimalizują liczbę fizycznych zależności między plikami. Używam ich od lat i zawsze byłem bardzo zadowolony z rezultatów.

1. Każdy plik CPP zawiera najpierw własny plik nagłówka. [fantastyczna okazja]
2. Plik nagłówka musi zawierać wszystkie pliki nagłówka niezbędne do jego przetworzenia. [fantastyczna okazja]
3. Plik nagłówkowy powinien mieć minimalną liczbę plików nagłówkowych niezbędnych do jego przetworzenia. [fantastyczna okazja]

Jeśli używasz Eclipse CDT, możesz wypróbować http://includator.com, który jest bezpłatny dla testerów wersji beta (w momencie pisania tego tekstu) i automatycznie usuwa zbędne #include lub dodaje brakujące. Dla tych użytkowników, którzy mają FlexeLint lub PC-Lint i używają Elicpse CDT, http://linticator.com może być opcją (również bezpłatną w wersji beta). Chociaż wykorzystuje analizę Linta, zapewnia szybkie poprawki do automatycznego usuwania zbędnych instrukcji #include.

W tym artykule wyjaśniono technikę #include usuwania przy użyciu parsowania Doxygen. To tylko skrypt perla, więc jest dość łatwy w użyciu.

Może trochę późno, ale kiedyś znalazłem skrypt perlowy WebKit, który zrobił dokładnie to, co chciałeś. Myślę, że będzie wymagało to pewnych dostosowań (nie znam się na perlu), ale powinno wystarczyć:

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

(jest to stara gałąź, ponieważ trunk nie ma już pliku)

Istnieje bezpłatne narzędzie Dołącz obserwator zależności plików, które można zintegrować ze studiem wizualnym. Pokazuje zbędne # zawiera w kolorze czerwonym.

Istnieją dwa rodzaje zbędnych plików #include:

1. Plik nagłówkowy faktycznie nie jest potrzebny modułowi (.c, .cpp)
2. Plik nagłówkowy jest potrzebny modułowi, ale jest dołączany więcej niż raz, bezpośrednio lub pośrednio.

W moim doświadczeniu są dwa sposoby, które dobrze go wykrywają:

• gcc -H lub cl.exe / showincludes (rozwiązać problem 2)

  W prawdziwym świecie możesz wyeksportować CFLAGS = -H przed marką, jeśli wszystkie pliki Makefile nie zastępują opcji CFLAGS. Lub, jak użyłem, możesz utworzyć opakowanie cc / g ++, aby wymusić dodanie opcji -H do każdego wywołania $ (CC) i $ (CXX). i dodaj katalog otoki do zmiennej $ PATH, wtedy twój make użyje zamiast tego polecenia otoki. Oczywiście twoje opakowanie powinno wywoływać prawdziwy kompilator gcc. Te sztuczki należy zmienić, jeśli Twój Makefile używa bezpośrednio gcc. zamiast $ (CC) lub $ (CXX) lub według zasad dorozumianych.

  Możesz także skompilować pojedynczy plik, dostosowując go za pomocą wiersza poleceń. Ale jeśli chcesz wyczyścić nagłówki dla całego projektu. Możesz przechwycić wszystkie dane wyjściowe poprzez:

  oczyścić

  zrób 2> i 1 | tee wynik.txt

• PC-Lint / FlexeLint (rozwiązać problem zarówno 1, jak i 2)

  pamiętaj, aby dodać opcje + e766, to ostrzeżenie dotyczy: nieużywanych plików nagłówka.

  pclint / flint -vf ...

  Spowoduje to, że pliki nagłówkowe pclint będą zawierać pliki nagłówkowe, zagnieżdżone pliki nagłówkowe zostaną odpowiednio wcięte.

Na zakończenie tej dyskusji: preprocesor c ++ jest w pełni gotowy. Jest to właściwość semantyczna, niezależnie od tego, czy dołączenie jest zbędne. Dlatego z twierdzenia Rice'a wynika, że ​​nie można rozstrzygnąć, czy dołączenie jest zbędne, czy nie. Nie może istnieć program, który (zawsze poprawnie) wykrywa, czy dołączenie jest zbyteczne.

Oto prosty sposób na identyfikację zbędnego nagłówka . Nie jest idealny, ale eliminuje „oczywiste” niepotrzebne elementy. Pozbywanie się ich jest bardzo pomocne w usuwaniu kodu.

Te skrypty są dostępne bezpośrednio na GitHub.

Komputer PC Lint firmy Gimpel Software może raportować, kiedy plik dołączania został dołączony więcej niż raz w jednostce kompilacyjnej , ale nie może znaleźć plików dołączonych, które nie są potrzebne w sposób, którego szukasz.

Edycja: może. Zobacz odpowiedź itsmatt

CLion , C / C ++ IDE od JetBrains, wykrywa zbędne dołączanie po wyjęciu z pudełka. Są one wyszarzone w edytorze, ale istnieją również funkcje optymalizujące zawarte w bieżącym pliku lub całym projekcie .

Odkryłem jednak, że płacisz za tę funkcjonalność; CLion potrzebuje trochę czasu, aby zeskanować i przeanalizować projekt po pierwszym załadowaniu.