Dans sa plupart (tous) des programmes sur lequel je travaille,
on trouve des #include a foison dans tous les sens (.h et .cpp).
Existe t'il des outils qui permettent :
- éliminer les #includes inutiles
- remplacer les #includes par des forward declarations quand c'est
possible (ou nécessaire)
- redescendre tous les #includes dans les fichier cpp
- redescendre tous les #includes dans les fichier cpp
Mauvais plan : un header devrait être autosuffisant, i.e. contenir lui-même les headers dont il a besoin.
En d'autres termes, un .cpp contenant uniquement
#include "machin.h"
doit pouvoir être compilé, quelque soit le header "machin.h".
Stephane Wirtel
Mauvais plan : un header devrait être autosuffisant, i.e. contenir lui-même les headers dont il a besoin.
En d'autres termes, un .cpp contenant uniquement
#include "machin.h"
doit pouvoir être compilé, quelque soit le header "machin.h".
Et les entêtes précompilées et la forward declaration ?
Sans le support des entêtes précompilées, le compilateur doit recompiler chaque .h, ce qui devient vite lourd quand on possède une arborescence de .h allucinante.
Me tromperais-je ?
Merci de confirmer, infirmer.
Stépahne
Mauvais plan : un header devrait être autosuffisant, i.e. contenir
lui-même les headers dont il a besoin.
En d'autres termes, un .cpp contenant uniquement
#include "machin.h"
doit pouvoir être compilé, quelque soit le header "machin.h".
Et les entêtes précompilées et la forward declaration ?
Sans le support des entêtes précompilées, le compilateur doit recompiler
chaque .h, ce qui devient vite lourd quand on possède une arborescence
de .h allucinante.
Mauvais plan : un header devrait être autosuffisant, i.e. contenir lui-même les headers dont il a besoin.
En d'autres termes, un .cpp contenant uniquement
#include "machin.h"
doit pouvoir être compilé, quelque soit le header "machin.h".
Et les entêtes précompilées et la forward declaration ?
Sans le support des entêtes précompilées, le compilateur doit recompiler chaque .h, ce qui devient vite lourd quand on possède une arborescence de .h allucinante.
Me tromperais-je ?
Merci de confirmer, infirmer.
Stépahne
Marc Boyer
Le 29-11-2005, Fabien LE LEZ a écrit :
On Tue, 29 Nov 2005 11:58:46 +0100, JBB :
- redescendre tous les #includes dans les fichier cpp
Mauvais plan : un header devrait être autosuffisant, i.e. contenir lui-même les headers dont il a besoin.
En d'autres termes, un .cpp contenant uniquement
#include "machin.h"
doit pouvoir être compilé, quelque soit le header "machin.h".
Vraiment ? Que veux-tu dire là ?
Je prends un exemple simple: ma classe Toto offre une fonction 'trier' qui enrobe un appel à 'sort' définit dans <algorithm>
Qui doit include <algorithm> ? Toto.hpp ou Toto.cpp ?
Marc Boyer -- Entre le fort et le faible, c'est la liberte qui opprime et le droit qui libere. Henri Lacordaire, Dominicain
Le 29-11-2005, Fabien LE LEZ <gramster@gramster.com> a écrit :
On Tue, 29 Nov 2005 11:58:46 +0100, JBB <merci@pasdespam.fr>:
- redescendre tous les #includes dans les fichier cpp
Mauvais plan : un header devrait être autosuffisant, i.e. contenir
lui-même les headers dont il a besoin.
En d'autres termes, un .cpp contenant uniquement
#include "machin.h"
doit pouvoir être compilé, quelque soit le header "machin.h".
Vraiment ?
Que veux-tu dire là ?
Je prends un exemple simple: ma classe Toto offre une
fonction 'trier' qui enrobe un appel à 'sort' définit
dans <algorithm>
Qui doit include <algorithm> ? Toto.hpp ou
Toto.cpp ?
Marc Boyer
--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain
Je prends un exemple simple: ma classe Toto offre une fonction 'trier' qui enrobe un appel à 'sort' définit dans <algorithm>
Qui doit include <algorithm> ? Toto.hpp ou Toto.cpp ?
Où est définie Toto::sort() - dans le .hpp (fonction inline) ou dans le .cpp ?
Oui, j'avais supposé que Toto::trier() était définit dans le .cpp, il manquait cette précision.
Marc Boyer -- Entre le fort et le faible, c'est la liberte qui opprime et le droit qui libere. Henri Lacordaire, Dominicain
Jean-Marc Bourguet
Stephane Wirtel writes:
Mauvais plan : un header devrait être autosuffisant, i.e. contenir lui-même les headers dont il a besoin.
Je suis d'accord, mais il y a une assez forte tradition (au moins en C, je ne me souviens pas avoir vu du code fait par les partisants de cette tradition en C++) qui ne veut pas d'include dans d'autres include. (Voir Pikes par exemple).
En d'autres termes, un .cpp contenant uniquement #include "machin.h" doit pouvoir être compilé, quelque soit le header "machin.h".
Et les entêtes précompilées et la forward declaration ?
Quel est le probleme? Tu mets les declarations qui font que ca compile plutot que d'inclure des definitions, nous sommes d'accord.
(Au fait, meme g++ et SparcWorks ont des en-tetes precompiles).
Sans le support des entêtes précompilées, le compilateur doit recompiler chaque .h, ce qui devient vite lourd quand on possède une arborescence de .h allucinante.
Je n'ai pas fait de mesure, il y a encore des compilateurs qui n'optimisent pas les gardes d'inclusion?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Mauvais plan : un header devrait être autosuffisant, i.e. contenir
lui-même les headers dont il a besoin.
Je suis d'accord, mais il y a une assez forte tradition (au moins en
C, je ne me souviens pas avoir vu du code fait par les partisants de
cette tradition en C++) qui ne veut pas d'include dans d'autres
include. (Voir Pikes par exemple).
En d'autres termes, un .cpp contenant uniquement #include
"machin.h" doit pouvoir être compilé, quelque soit le header
"machin.h".
Et les entêtes précompilées et la forward declaration ?
Quel est le probleme? Tu mets les declarations qui font que ca
compile plutot que d'inclure des definitions, nous sommes d'accord.
(Au fait, meme g++ et SparcWorks ont des en-tetes precompiles).
Sans le support des entêtes précompilées, le compilateur doit
recompiler chaque .h, ce qui devient vite lourd quand on possède une
arborescence de .h allucinante.
Je n'ai pas fait de mesure, il y a encore des compilateurs qui
n'optimisent pas les gardes d'inclusion?
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Mauvais plan : un header devrait être autosuffisant, i.e. contenir lui-même les headers dont il a besoin.
Je suis d'accord, mais il y a une assez forte tradition (au moins en C, je ne me souviens pas avoir vu du code fait par les partisants de cette tradition en C++) qui ne veut pas d'include dans d'autres include. (Voir Pikes par exemple).
En d'autres termes, un .cpp contenant uniquement #include "machin.h" doit pouvoir être compilé, quelque soit le header "machin.h".
Et les entêtes précompilées et la forward declaration ?
Quel est le probleme? Tu mets les declarations qui font que ca compile plutot que d'inclure des definitions, nous sommes d'accord.
(Au fait, meme g++ et SparcWorks ont des en-tetes precompiles).
Sans le support des entêtes précompilées, le compilateur doit recompiler chaque .h, ce qui devient vite lourd quand on possède une arborescence de .h allucinante.
Je n'ai pas fait de mesure, il y a encore des compilateurs qui n'optimisent pas les gardes d'inclusion?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
Marc Boyer writes:
Le 29-11-2005, Fabien LE LEZ a écrit :
On Tue, 29 Nov 2005 11:58:46 +0100, JBB :
- redescendre tous les #includes dans les fichier cpp
Mauvais plan : un header devrait être autosuffisant, i.e. contenir lui-même les headers dont il a besoin.
En d'autres termes, un .cpp contenant uniquement
#include "machin.h"
doit pouvoir être compilé, quelque soit le header "machin.h".
Vraiment ?
Oui.
Que veux-tu dire là ?
Que n'importe quel en-tete devrait pouvoir etre la premiere chose include dans une unite de compilation. Une technique habituelle est de l'inclure en premier lieu dans le fichier qui contient les definitions correspondantes.
Je prends un exemple simple: ma classe Toto offre une fonction 'trier' qui enrobe un appel à 'sort' définit dans <algorithm>
Qui doit include <algorithm> ? Toto.hpp ou Toto.cpp ?
Toto.hpp s'il a besoin de <algorithm>, Toto.cpp sinon.
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Le 29-11-2005, Fabien LE LEZ <gramster@gramster.com> a écrit :
On Tue, 29 Nov 2005 11:58:46 +0100, JBB <merci@pasdespam.fr>:
- redescendre tous les #includes dans les fichier cpp
Mauvais plan : un header devrait être autosuffisant, i.e. contenir
lui-même les headers dont il a besoin.
En d'autres termes, un .cpp contenant uniquement
#include "machin.h"
doit pouvoir être compilé, quelque soit le header "machin.h".
Vraiment ?
Oui.
Que veux-tu dire là ?
Que n'importe quel en-tete devrait pouvoir etre la premiere chose
include dans une unite de compilation. Une technique habituelle est
de l'inclure en premier lieu dans le fichier qui contient les
definitions correspondantes.
Je prends un exemple simple: ma classe Toto offre une fonction
'trier' qui enrobe un appel à 'sort' définit dans <algorithm>
Qui doit include <algorithm> ? Toto.hpp ou Toto.cpp ?
Toto.hpp s'il a besoin de <algorithm>, Toto.cpp sinon.
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
- redescendre tous les #includes dans les fichier cpp
Mauvais plan : un header devrait être autosuffisant, i.e. contenir lui-même les headers dont il a besoin.
En d'autres termes, un .cpp contenant uniquement
#include "machin.h"
doit pouvoir être compilé, quelque soit le header "machin.h".
Vraiment ?
Oui.
Que veux-tu dire là ?
Que n'importe quel en-tete devrait pouvoir etre la premiere chose include dans une unite de compilation. Une technique habituelle est de l'inclure en premier lieu dans le fichier qui contient les definitions correspondantes.
Je prends un exemple simple: ma classe Toto offre une fonction 'trier' qui enrobe un appel à 'sort' définit dans <algorithm>
Qui doit include <algorithm> ? Toto.hpp ou Toto.cpp ?
Toto.hpp s'il a besoin de <algorithm>, Toto.cpp sinon.
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ
On Tue, 29 Nov 2005 14:30:22 +0000 (UTC), Marc Boyer :
Je prends un exemple simple: ma classe Toto offre une fonction 'trier' qui enrobe un appel à 'sort' définit dans <algorithm>
Qui doit include <algorithm> ? Toto.hpp ou Toto.cpp ?
Si quelque chose de défini dans <algorithm> est utilisé dans toto.hpp, il faut inclure <algorithm> dans toto.hpp.
Si l'appel à std::sort() est mis dans le .hpp, tu dois y inclure <algorithm>.
On Tue, 29 Nov 2005 14:30:22 +0000 (UTC), Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid>:
Je prends un exemple simple: ma classe Toto
offre une fonction 'trier' qui enrobe un appel à 'sort' définit
dans <algorithm>
Qui doit include <algorithm> ? Toto.hpp ou
Toto.cpp ?
Si quelque chose de défini dans <algorithm> est utilisé dans toto.hpp,
il faut inclure <algorithm> dans toto.hpp.
Si l'appel à std::sort() est mis dans le .hpp, tu dois y inclure
<algorithm>.
On Tue, 29 Nov 2005 14:30:22 +0000 (UTC), Marc Boyer :
Je prends un exemple simple: ma classe Toto offre une fonction 'trier' qui enrobe un appel à 'sort' définit dans <algorithm>
Qui doit include <algorithm> ? Toto.hpp ou Toto.cpp ?
Si quelque chose de défini dans <algorithm> est utilisé dans toto.hpp, il faut inclure <algorithm> dans toto.hpp.
Si l'appel à std::sort() est mis dans le .hpp, tu dois y inclure <algorithm>.
Fabien LE LEZ
On Tue, 29 Nov 2005 14:40:34 +0000 (UTC), Marc Boyer :
Oui, j'avais supposé que Toto::trier() était définit dans le .cpp, il manquait cette précision.
Dans ce cas, le fait que std::sort() soit utilisée n'a rien à voir avec le .hpp.
Fais l'expérience : crée un fichier test.cpp ne contenant rien d'autre que #include "toto.hpp" et essaie de le compiler. Accesoirement, fais aussi le test avec n'importe quel header de la SL, ça m'étonnerait beaucoup que ça ne compile pas.
On Tue, 29 Nov 2005 14:40:34 +0000 (UTC), Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid>:
Oui, j'avais supposé que Toto::trier() était définit
dans le .cpp, il manquait cette précision.
Dans ce cas, le fait que std::sort() soit utilisée n'a rien à voir
avec le .hpp.
Fais l'expérience : crée un fichier test.cpp ne contenant rien d'autre
que
#include "toto.hpp"
et essaie de le compiler.
Accesoirement, fais aussi le test avec n'importe quel header de la SL,
ça m'étonnerait beaucoup que ça ne compile pas.
On Tue, 29 Nov 2005 14:40:34 +0000 (UTC), Marc Boyer :
Oui, j'avais supposé que Toto::trier() était définit dans le .cpp, il manquait cette précision.
Dans ce cas, le fait que std::sort() soit utilisée n'a rien à voir avec le .hpp.
Fais l'expérience : crée un fichier test.cpp ne contenant rien d'autre que #include "toto.hpp" et essaie de le compiler. Accesoirement, fais aussi le test avec n'importe quel header de la SL, ça m'étonnerait beaucoup que ça ne compile pas.
Marc Boyer
Le 29-11-2005, Fabien LE LEZ a écrit :
On Tue, 29 Nov 2005 14:40:34 +0000 (UTC), Marc Boyer :
Oui, j'avais supposé que Toto::trier() était définit dans le .cpp, il manquait cette précision.
Dans ce cas, le fait que std::sort() soit utilisée n'a rien à voir avec le .hpp.
Fais l'expérience : crée un fichier test.cpp ne contenant rien d'autre que #include "toto.hpp" et essaie de le compiler. Accesoirement, fais aussi le test avec n'importe quel header de la SL, ça m'étonnerait beaucoup que ça ne compile pas.
Nous sommes d'accord. J'avais mal compris ta remarque.
Désolé pour le dérangement.
Marc Boyer -- Entre le fort et le faible, c'est la liberte qui opprime et le droit qui libere. Henri Lacordaire, Dominicain
Le 29-11-2005, Fabien LE LEZ <gramster@gramster.com> a écrit :
On Tue, 29 Nov 2005 14:40:34 +0000 (UTC), Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid>:
Oui, j'avais supposé que Toto::trier() était définit
dans le .cpp, il manquait cette précision.
Dans ce cas, le fait que std::sort() soit utilisée n'a rien à voir
avec le .hpp.
Fais l'expérience : crée un fichier test.cpp ne contenant rien d'autre
que
#include "toto.hpp"
et essaie de le compiler.
Accesoirement, fais aussi le test avec n'importe quel header de la SL,
ça m'étonnerait beaucoup que ça ne compile pas.
Nous sommes d'accord. J'avais mal compris ta remarque.
Désolé pour le dérangement.
Marc Boyer
--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain
On Tue, 29 Nov 2005 14:40:34 +0000 (UTC), Marc Boyer :
Oui, j'avais supposé que Toto::trier() était définit dans le .cpp, il manquait cette précision.
Dans ce cas, le fait que std::sort() soit utilisée n'a rien à voir avec le .hpp.
Fais l'expérience : crée un fichier test.cpp ne contenant rien d'autre que #include "toto.hpp" et essaie de le compiler. Accesoirement, fais aussi le test avec n'importe quel header de la SL, ça m'étonnerait beaucoup que ça ne compile pas.
Nous sommes d'accord. J'avais mal compris ta remarque.
Désolé pour le dérangement.
Marc Boyer -- Entre le fort et le faible, c'est la liberte qui opprime et le droit qui libere. Henri Lacordaire, Dominicain
