Discussion :

[killwin]

Bonsoir,

Existe t'il un outil capable d'indiquer les #include en trop ou qui servent à rien ?

Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
 
A.h
#include <iostream>
 
B.h
#include "A.h"
 
C.h
#include "B.h"
#include <iostream> // include en trop

PS : Je suis sous linux, je développe avec Qt / vim

Merci d'avance

[balhrog]

Bonjour,
En utilisant bien les

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#IFNDEF

tu peux réussir à te protéger des inclusions multiples.
Ou sinon, tu peux passer par un programme DIY (c'est pas très dur)

[Bousk]

Tu es dans le cas d'un include doublé, pas forcément en trop.
Un include en trop, ça incluerait du code inutile, ça a un cout sur la compilation et fait perdre du temps.
> Il serait en trop si dans C.h tu n'utilises rien de iostream.
Un include doublé, ça n'a (quasi)aucune incidence. Le fichier est déjà inclus, il sera vite ignoré par le préprocesseur si le fichier est correctement formé : #pragma once, header guards.
> Si C.h utilise iostream, tu ne devrais pas supprimer son include. Si plus tard tu supprimes l'include dans A.h, tu dois aussi modifier C.h : y'a rien de plus chiant qu'une compilation qui échoue dans un autre fichier quand tu supprimes des includes.

[killwin]

Merci pour la réponse, j'ai oublié de préciser que j'ai bien des headers guards sur mes .h . L'idée c'était surtout pour purifier mon code, pour une question de lisibilité plus que pour une question de performance. Je vais du coup regarder ce que ça donne avec doxygen.

[ternel]

Une solution "simple", c'est d'en enlever et de voir.

Attention tout de même à ne pas tomber dans l'excès inverse.
Certains en-têtes en incluent d'autres pour des raisons pratiques (par exemple chez moi <iostream> inclue <string>), mais il faut quand même les inclure soit même si on en a besoin. Parce que les sous-dépendances peuvent changer.

Si ton entête utilise une std::string, il doit inclure <string>.

[bacelar]

Je ne comprends pas le problème.
On inclut tout ce qui est nécessaire à ce que l'on utilise mais uniquement à ce que l'on utilise.
Si ça compile en enlevant un include, cela ne justifie en rien son éviction (c'est tombé en marche).
Les dépendances d'une classe doit être conçu en amont du processus de conception de la classe et donc ne devrait pas changer inopinément.
S'il y a refactoring de la classe, un petit tour rapide dans les includes pour ajouter ou supprimer les dépendances en fonction du refactoring fera l'affaire et sera très rapide à faire.

Plus qu'un détail technique, les includes sont une espèce de déclaration informelle des dépendances du code qui va suivre.

Je suis donc en parfaite adéquation avec @Bousk et en opposition avec @ternel (pour une fois ).

[Bktero]

Je viens de voir ça : https://include-what-you-use.org/ J'utilise CLion en ce moment et il le fait ce genre de vérification à la volée.

Je me méfie moi aussi des includes qui ne serviraient à rien, justement pour le problème décrit pas bacelar. Si tu inclues un fichier qui inclus un autre fichier qui en inclus enfin "toto.hpp", alors tu pourrais te passer d'inclure toi-aussi "toto.hpp" alors que tu utilises toi aussi la classe Toto. Et un jour, les fichiers intermédiaires changent et "toto.hpp", que tu avais de manière indirecte, n'est plus là et tu as une erreur de compilation que tu peux mettre du temps à comprendre.

[koala01]

Salut,

De manière générale, il n'est jamais mauvais de veiller à n'inclure que ce qui est strictement nécessaire. Ne serait-ce que parce que, sous Gcc, le simple fait de d'inclure <iostream> rajoute... 25 000 lignes de code (et plus) à une unité de compilation. Et ce n'est bien sur qu'un exemple parmi tant d'autres!

Du coup, l'idéal est de préférer les ==>déclarations anticipées<== à chaque fois que tu peux te le permettre. Inclure <iosfwd> qui ne contient que les déclarations anticipée des différentes fonctionnalités offertes par les différent fichiers d'en-tête *stream, par exemple, n'incluera que ... 1 500 ligne de code environ, mais sera suffisant pour bien des utilisations (du moins, au niveau d'un fichier d'en-tête).

Ensuite, je "m'amuse" régulièrement à "épurer" le diagramme d'inclusion généré par doxygen. Je trouve que cela rend la documentation bien plus simple à comprendre. Mais cela doit être fait avec "calme et méthode" si on veut éviter les catastrophes.

Entre autres, il est important de veiller à ce que la compilation continue à s'effectuer après chaque suppression d'une directive include, car, si tu attends d'en avoir supprimé plusieurs, et que la compilation échoue à cause d'un identifiant inconnu, tu risques d'avoir du mal à retrouver le fichier supprimé par mégarde

[ternel]

Je ne comprends pas le problème.
On inclut tout ce qui est nécessaire à ce que l'on utilise mais uniquement à ce que l'on utilise.
Si ça compile en enlevant un include, cela ne justifie en rien son éviction (c'est tombé en marche).
Les dépendances d'une classe doit être conçu en amont du processus de conception de la classe et donc ne devrait pas changer inopinément.
S'il y a refactoring de la classe, un petit tour rapide dans les includes pour ajouter ou supprimer les dépendances en fonction du refactoring fera l'affaire et sera très rapide à faire.

Plus qu'un détail technique, les includes sont une espèce de déclaration informelle des dépendances du code qui va suivre.

Je suis donc en parfaite adéquation avec @Bousk et en opposition avec @ternel (pour une fois ).

C'est justement ce que j'ai dis

[Luc Hermitte]

Il y a effectivement IWYU qui vient avec clang & cie. Par contre il faut vraiment passer derrière -- p.ex. il ne va pas forcément gérer mon point 2- comme je le voudrais, il va aussi avoir du mal avec des fichiers frontaux à destination des utilisateurs.

Ma politique: si j'utilise un symbole dans un fichier, par ordre de priorité (cf les chiffres en désordre):

1- déclaration anticipée (ou inclusion de fichier d'en-tête ne contenant que des déclarations anticipées comme <iosfwd>) quand je n'ai besoin que de la déclaration, en particulier dans le cas de l'écriture de fichiers d'en-tête
3- si j'ai besoin de la définition, j'inclus le fichier d'en-tête qui le définit
2- sauf si je sais qu'il y a une dépendance forte entre des fichiers d'en-tête déjà (obligatoirement) inclus (à tout jamais) et le truc dont j'ai besoin. Genre dans toto.cpp, je ne reprends pas les inclusions de toto.h(pp). Ou si dans B.h(pp) je définis la classe B qui hérite de la classe A définie dans A.h(pp), et que j'ai de nouveau besoin de types qui servent à la définition de A (genre des conteneurs/chaines standards), je ne ré-inclus pas les fichiers d'en-têtes où ils sont définis (<vector>, <string>...)
4- après, j'essaie d'être minimaliste, p.ex. je n'inclus <iostream> que si j'utilise explicitement std::cout & cie. Quand j'ai besoin de la définition de std::ostream (pour écrire un opérateur de flux p.ex.), j'inclus donc <ostream>. Si je ne fais que déclarer un opérateur de flux, c'est <iosfwd> que j'inclus.

[killwin]

Merci pour ces différentes réponses et ces différents points de vue. Je constate que la problématique est simple mais est sujette à débat ^^. Je vais analyser chacune des réponses cette semaine

[oodini]

Il existe Includator pour virer les include inutiles.
Jamais essayé, toutefois.