Détecter les #inclusions superflus en C / C ++?

Je trouve souvent que la section des en-têtes d'un fichier devient de plus en plus grande tout le temps, mais elle ne diminue jamais. Tout au long de la vie d'un fichier source, les classes peuvent avoir été déplacées et refactorisées et il est très possible qu'il y en ait plusieurs #includesqui n'ont plus besoin d'être là et plus. Les laisser là ne fait que prolonger le temps de compilation et ajoute des dépendances de compilation inutiles. Essayer de comprendre celles qui sont encore nécessaires peut être assez fastidieux.

Existe-t-il une sorte d'outil qui peut détecter les directives #include superflues et suggérer celles que je peux supprimer en toute sécurité?
La charpie fait-elle cela peut-être?

Ce n'est pas automatique, mais doxygen produira des diagrammes de dépendance pour les #includedfichiers. Vous devrez les parcourir visuellement, mais ils peuvent être très utiles pour obtenir une image de ce qui utilise quoi.

Le cppclean de Google (liens vers: téléchargement , documentation ) peut trouver plusieurs catégories de problèmes C ++, et il peut désormais trouver des #includes superflus.

Il existe également un outil basé sur Clang, notamment ce que vous utilisez , qui peut le faire. include-what-you-use peut même suggérer des déclarations avancées (afin que vous n'ayez pas à en inclure autant) et éventuellement nettoyer vos #includes pour vous.

Les versions actuelles d' Eclipse CDT intègrent également cette fonctionnalité: passer sous le menu Source et cliquer sur Organiser comprend alphabétisera vos # inclus, ajoutera tous les en-têtes qu'Eclipse pense que vous utilisez sans les inclure directement et commente tous les en-têtes qu'il ne fait pas pensez pas que vous avez besoin. Cependant, cette fonctionnalité n'est pas fiable à 100%.

Consultez également include-what-you-use , qui résout un problème similaire.

Le problème avec la détection d'inclusions superflues est qu'il ne peut pas être juste un vérificateur de dépendance de type. Une inclusion superflue est un fichier qui n'apporte rien de valeur à la compilation et ne modifie pas un autre élément dont dépendent les autres fichiers. Il existe de nombreuses façons dont un fichier d'en-tête peut modifier une compilation, par exemple en définissant une constante, en redéfinissant et / ou en supprimant une macro utilisée, en ajoutant un espace de noms qui modifie la recherche d'un nom quelque part sur la ligne. Afin de détecter des éléments comme l'espace de noms dont vous avez besoin de bien plus qu'un préprocesseur, vous avez en fait presque besoin d'un compilateur complet.

Lint est plus un vérificateur de style et n'aura certainement pas cette pleine capacité.

Je pense que vous trouverez le seul moyen de détecter une inclusion superflue: supprimer, compiler et exécuter des suites.

Je pensais que PCLint ferait cela, mais cela fait quelques années que je ne l'ai pas examiné. Vous pourriez le vérifier.

J'ai regardé ce blog et l'auteur a parlé un peu de la configuration de PCLint pour trouver les inclusions inutilisées. Ça vaut peut-être le coup d'oeil.

Le navigateur de refactoring CScout peut détecter les directives d'inclusion superflues dans le code C (malheureusement pas C ++). Vous pouvez trouver une description de son fonctionnement dans cet article de journal.

Vous pouvez écrire un script rapide qui efface une seule directive #include, compile les projets et enregistre le nom dans le #include et le fichier dont il a été supprimé dans le cas où aucune erreur de compilation ne s'est produite.

Laissez-le fonctionner pendant la nuit, et le lendemain, vous aurez une liste 100% correcte des fichiers d'inclusion que vous pouvez supprimer.

Parfois, la force brute fonctionne :-)

edit: et parfois ce n'est pas :-). Voici quelques informations tirées des commentaires:

1. Parfois, vous pouvez supprimer deux fichiers d'en-tête séparément, mais pas les deux ensemble. Une solution consiste à supprimer les fichiers d'en-tête pendant l'exécution et à ne pas les récupérer. Cela trouvera une liste de fichiers que vous pouvez supprimer en toute sécurité, bien qu'il puisse y avoir une solution avec plus de fichiers à supprimer que cet algorithme ne trouvera pas. (c'est une recherche gourmande sur l'espace des fichiers à supprimer. Il ne trouvera qu'un maximum local)
2. Il peut y avoir de subtils changements de comportement si certaines macros sont redéfinies différemment selon certains #ifdefs. Je pense que ce sont des cas très rares, et les tests unitaires qui font partie de la construction devraient détecter ces changements.

Désolé de (re) poster ici, les gens ne développent souvent pas de commentaires.

Vérifiez mon commentaire à crashmstr, FlexeLint / PC-Lint fera cela pour vous. Message d'information 766. La section 11.8.1 de mon manuel (version 8.0) en discute.

De plus, et c'est important, continuez à répéter jusqu'à ce que le message disparaisse . En d'autres termes, après avoir supprimé les en-têtes inutilisés, relancez lint, d'autres fichiers d'en-tête peuvent être devenus "inutiles" une fois que vous avez supprimé certains en-têtes inutiles. (Cela peut sembler idiot, lisez-le lentement et analysez-le, cela a du sens.)

Je n'ai jamais trouvé d'outil à part entière qui accomplisse ce que vous demandez. La chose la plus proche que j'ai utilisée est IncludeManager , qui représente votre arbre d'inclusion d'en-tête afin que vous puissiez repérer visuellement des éléments tels que des en-têtes inclus dans un seul fichier et des inclusions d'en-tête circulaires.

J'ai essayé d'utiliser Flexelint (la version unix de PC-Lint) et j'ai eu des résultats quelque peu mitigés. C'est probablement parce que je travaille sur une base de code très volumineuse et noueuse. Je recommande d'examiner attentivement chaque fichier signalé comme inutilisé.

La principale inquiétude concerne les faux positifs. Plusieurs inclusions du même en-tête sont signalées comme un en-tête inutile. C'est mauvais car Flexelint ne vous dit pas sur quelle ligne l'en-tête est inclus ni où il a été inclus auparavant.

Une des façons dont les outils automatisés peuvent se tromper:

Dans A.hpp:

class A { 
  // ...
};

Dans B.hpp:

#include "A.hpp

class B {
    public:
        A foo;
};

Dans 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

Si vous suivez aveuglément les messages de Flexelint, vous ferez le ménage dans vos dépendances #include. Il y a plus de cas pathologiques, mais fondamentalement, vous devrez inspecter les en-têtes vous-même pour de meilleurs résultats.

Je recommande fortement cet article sur la structure physique et le C ++ du blog Games from inside. Ils recommandent une approche globale pour nettoyer le gâchis #include:

Des lignes directrices

Voici un ensemble distillé de directives du livre de Lakos qui minimisent le nombre de dépendances physiques entre les fichiers. Je les utilise depuis des années et j'ai toujours été très satisfait des résultats.

1. Chaque fichier cpp comprend d'abord son propre fichier d'en-tête. [couper]
2. Un fichier d'en-tête doit inclure tous les fichiers d'en-tête nécessaires à son analyse. [couper]
3. Un fichier d'en-tête doit avoir le nombre minimal de fichiers d'en-tête nécessaires pour l'analyser. [couper]

Si vous utilisez Eclipse CDT, vous pouvez essayer http://includator.com qui est gratuit pour les bêta-testeurs (au moment d'écrire ces lignes) et supprime automatiquement les #includes superflus ou ajoute ceux qui manquent. Pour les utilisateurs qui ont FlexeLint ou PC-Lint et utilisent Elicpse CDT, http://linticator.com peut être une option (également gratuit pour le test bêta). Bien qu'il utilise l'analyse de Lint, il fournit des solutions rapides pour supprimer automatiquement les instructions #include superflues.

Cet article explique une technique de suppression de #include en utilisant l'analyse de Doxygen. Ce n'est qu'un script perl, il est donc assez facile à utiliser.

Peut-être un peu tard, mais j'ai déjà trouvé un script Perl WebKit qui faisait exactement ce que vous vouliez. Il faudra un peu d'adaptation je crois (je ne connais pas bien le perl), mais ça devrait faire l'affaire:

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

(c'est une ancienne branche car le tronc n'a plus le fichier)

Il existe un outil gratuit Include File Dependencies Watcher qui peut être intégré dans le studio visuel. Il montre # superflu comprend en rouge.

Il existe deux types de fichiers #include superflus:

1. Un fichier d'en-tête qui n'est pas du tout nécessaire au module (.c, .cpp)
2. Un fichier d'en-tête est requis par le module mais il est inclus plusieurs fois, directement ou indirectement.

Il y a 2 façons dans mon expérience qui fonctionnent bien pour le détecter:

• gcc -H ou cl.exe / showincludes (résoudre le problème 2)

  Dans le monde réel, vous pouvez exporter CFLAGS = -H avant make, si toutes les options CFLAGS du Makefile ne remplacent pas. Ou comme je l'ai utilisé, vous pouvez créer un wrapper cc / g ++ pour ajouter des options -H de force à chaque appel de $ (CC) et $ (CXX). et ajoutez le répertoire du wrapper à la variable $ PATH, alors votre make utilisera à la place votre commande wrapper. Bien sûr, votre wrapper doit invoquer le vrai compilateur gcc. Ces astuces doivent changer si votre Makefile utilise directement gcc. au lieu de $ (CC) ou $ (CXX) ou par des règles implicites.

  Vous pouvez également compiler un seul fichier en peaufinant avec la ligne de commande. Mais si vous voulez nettoyer les en-têtes de l'ensemble du projet. Vous pouvez capturer toutes les sorties en:

  nettoyer

  faire 2> & 1 | tee result.txt

• PC-Lint / FlexeLint (résoudre les problèmes 1 et 2)

  assurez-vous d'ajouter les options + e766, cet avertissement concerne: les fichiers d'en-tête inutilisés.

  pclint / flint -vf ...

  Cela entraînera la sortie pclint des fichiers d'en-tête inclus, les fichiers d'en-tête imbriqués seront mis en retrait de manière appropriée.

Pour terminer cette discussion: le préprocesseur c ++ est terminé. C'est une propriété sémantique, qu'une inclusion soit superflue. Par conséquent, il résulte du théorème de Rice qu'il est indécidable si une inclusion est superflue ou non. Il NE PEUT PAS y avoir de programme qui (toujours correctement) détecte si une inclusion est superflue.

Voici un moyen simple, par force brute, d'identifier les en-têtes superflus . Ce n'est pas parfait, mais élimine les inclusions inutiles "évidentes". Se débarrasser de ceux-ci va un long chemin dans le nettoyage du code.

Les scripts sont accessibles directement sur GitHub.

PC Lint de Gimpel Software peut signaler lorsqu'un fichier inclus a été inclus plus d'une fois dans une unité de compilation , mais il ne peut pas trouver les fichiers inclus qui ne sont pas nécessaires comme vous le recherchez.

Edit: C'est possible. Voir la réponse de itsmatt

CLion , l'IDE C / C ++ de JetBrains, détecte les inclusions redondantes prêtes à l'emploi . Celles-ci sont grisées dans l'éditeur, mais il existe également des fonctions permettant d' optimiser les inclusions dans le fichier en cours ou l'ensemble du projet .

J'ai trouvé que vous payez pour cette fonctionnalité; CLion prend un certain temps pour numériser et analyser votre projet lors du premier chargement.