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 ).