C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Emplacement des #include          C++Talk.NET Forum Index -> C++ (French) View previous topic :: View next topic   Author Message Jean-Noël Mégoz Guest Posted: Wed Apr 07, 2004 2:27 pm    Post subject: Emplacement des #include Bonjour, Je potasse actuellement un cours de C++ et je viens de réaliser un truc qui me chiffonne dans un exemple : -- Book.h ------------------------------------- #ifndef BOOK_H #define BOOK_H class Reader; class Reservation; class Book { friend class Reservation; private: list<Reservation*> reserv; [...] public: [...] }; #endif -- Book.cpp ----------------------------------- #include <list> using namespace std; #include "Reader.h" #include "Book.h" #include "Reservation.h" [...] ----------------------------------------------- A priori, j'aurais mis les #include dans le .h plutôt que dans le .cpp (chose que j'ai l'habitude de faire en C). J'aurais alors peut-être eu besoin de répéter l'include de <list> dans chacun des .h, mais le but n'est-il pas justement de mettre dans ce fichier tout ce qui est nécessaire au .cpp, autre que le code ? J'entends par là qu'un éventuel repreneur du module doit, en ne consultant que le .h, savoir tout de suite ce qui est appelé et appelable... La solution proposée ici est-elle équivalente/meilleure/la seule envisageable ? Pourquoi ? J.No. Back to top Matthieu Moy Guest Posted: Wed Apr 07, 2004 2:41 pm    Post subject: Re: Emplacement des #include "Jean-Noël Mégoz" <nospam_jnmegoz (AT) infonie (DOT) fr> writes: Quote: A priori, j'aurais mis les #include dans le .h plutôt que dans le .cpp (chose que j'ai l'habitude de faire en C). Ce n'est pas une super habitude ... Quote: J'aurais alors peut-être eu besoin de répéter l'include de <list> dans chacun des .h, mais le but n'est-il pas justement de mettre dans ce fichier tout ce qui est nécessaire au .cpp, autre que le code ? Les include du .h sont ceux qui sont nécessaires au .h. Principalement les définitions de types, et les fonctions utilisées dans les fonctions inline du .h. Une bonne habitude est de faire des .h appelables « tout seul », c'est à dire que toutes les dépendances du .h doivent être dans le .h. Une mauvaise habitude est de faire un fichier toto.h qui a besoin de titi.h, ce qui oblige l'appelant à écrire toujours un « #include "titi.h" » avant chaque « #include "toto.h" ». Mais si tu utilise, en interne, le type list, alors le #include ne doit venir que dans le .cpp. Les utilisateurs de ton module n'ont pas envie de savoir si tes algorithmes utilisent list, vector, ou encore autre chose. Ca alourdirait le .h, polluerait ton espace de nom, et ralentirait même la compilation. Bref : ..h = interface ..cpp = implémentation En particulier, si un jour tu as des dépendances croisées A.h B.h ^ / ^ Quote: X | / | A.cpp B.cpp Tu ne pourra pas faire autrement sous peine de dépendances cycliques. -- Matthieu Back to top Jean-Noël Mégoz Guest Posted: Wed Apr 07, 2004 2:52 pm    Post subject: Re: Emplacement des #include "Matthieu Moy" <MatthieuNOSPAM.Moy (AT) imag (DOT) fr.invalid> a écrit dans le message de news:vpqisgb3l6o.fsf (AT) ecrins (DOT) imag.fr... Quote: "Jean-Noël Mégoz" <nospam_jnmegoz (AT) infonie (DOT) fr> writes: A priori, j'aurais mis les #include dans le .h plutôt que dans le .cpp (chose que j'ai l'habitude de faire en C). Ce n'est pas une super habitude ... [...] En particulier, si un jour tu as des dépendances croisées A.h B.h ^ / ^ | X | | / | A.cpp B.cpp Tu ne pourra pas faire autrement sous peine de dépendances cycliques. Maintenant que tu le dis, je comprends mon erreur. Et je comprends pourquoi, ayant déjà rencontré ce problème de dépendances croisées, je n'avais alors pu le résoudre qu'en fusionnant A.h et B.h en un seul fichier... Merci. J.No. Back to top Jean-Marc Bourguet Guest Posted: Wed Apr 07, 2004 3:29 pm    Post subject: Re: Emplacement des #include "Jean-Noël Mégoz" <nospam_jnmegoz (AT) infonie (DOT) fr> writes: Quote: La solution proposée ici est-elle équivalente/meilleure/la seule envisageable ? Il y a deux ecoles - ceux qui ne mettent aucun #include dans un .hxx - ceux qui considere qu'un fichier ne contenant que #include "foo.hxx" doit pouvoir compiler quel que soit foo.hxx Je fais partie de la seconde -- et plus je touche des projets ou des gens de la premiere ont sevi, plus je suis convaincu que ma position est la bonne. Mais naturellement, il ne faut pas mettre des #include quand une declaration suffit. 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 Back to top Fabien LE LEZ Guest Posted: Wed Apr 07, 2004 6:13 pm    Post subject: Re: Emplacement des #include On 07 Apr 2004 17:29:57 +0200, Jean-Marc Bourguet <jm (AT) bourguet (DOT) org> wrote: Quote: - ceux qui considere qu'un fichier ne contenant que #include "foo.hxx" doit pouvoir compiler quel que soit foo.hxx C'est également mon avis. Par contre, ce qui me chiffonne sérieusement dans le message de Jean-Noël, c'est le "using namespace std;" avant certains #include. AMHA, aucun #include ne doit se trouver après une directive "using". -- ;-) Back to top Loïc Joly Guest Posted: Wed Apr 07, 2004 7:19 pm    Post subject: Re: Emplacement des #include Jean-Noël Mégoz wrote: Quote: Bonjour, Je potasse actuellement un cours de C++ et je viens de réaliser un truc qui me chiffonne dans un exemple : -- Book.h ------------------------------------- #ifndef BOOK_H #define BOOK_H class Reader; class Reservation; class Book { friend class Reservation; private: list<Reservation*> reserv; [...] public: [...] }; #endif Un bon principe AMA est qu'un .h doit pouvoir être inclus sans rien mettre devant. Un autre principe est d'éviter s'inclure ce qui n'est pas nécessaire, pour minimiser les dépendances entre fichiers. Dans cet exemple, je suis d'accord avec les class Reader; class Reservation; Mais par contre, la classe a besoin d'utiliser list (std::list ?), et j'ajouterai un #include <list>. Enfin, ce .h suppose l'utilisation d'un using namespace, ce qui est moche. Quote: -- Book.cpp ----------------------------------- #include using namespace std; #include "Reader.h" #include "Book.h" #include "Reservation.h" [...] ----------------------------------------------- J'ai pris l'habitude d'include dans un .cpp le .h correspondant en premier, ainsi, je suis certain que ce .h peut être inclus sans rien d'autre devant. -- Loïc Back to top kanze@gabi-soft.fr Guest Posted: Thu Apr 08, 2004 7:29 am    Post subject: Re: Emplacement des #include Jean-Marc Bourguet <jm (AT) bourguet (DOT) org> wrote Quote: "Jean-Noël Mégoz" <nospam_jnmegoz (AT) infonie (DOT) fr> writes: La solution proposée ici est-elle équivalente/meilleure/la seule envisageable ? Il y a deux ecoles - ceux qui ne mettent aucun #include dans un .hxx - ceux qui considere qu'un fichier ne contenant que #include "foo.hxx" doit pouvoir compiler quel que soit foo.hxx Je fais partie de la seconde -- et plus je touche des projets ou des gens de la premiere ont sevi, plus je suis convaincu que ma position est la bonne. Je crois que de nos jours, il s'est fait un consensus pour la seconde. Ce n'était pas toujours le cas, voir http://www.lysator.liu.se/c/pikestyle.html, par exemple. (Mais je me démande si Pike aurait écrit les mêmes choses aujourd'hui. J'avoue avoir été déçu de son dernier livre -- il semblait trop un voyage dans la passée, avec des conseils sur où on a été, mais qui ne convenait pas forcément aujourd'hui, malgré leurs efforts de les actualiser.) Pour la reste, j'avoue ne jamais avoir eu à travailler avec du code de la première école. Quand ce n'était pas la seconde école, c'était à peu près n'importe quoi. Ceci dit, ce n'est pas toujours évident à enforcer la seconde école. Pour prendre un exemple un peu bête, si j'écris une classe qui dérive de std::streambuf, et qui contient un membre de type std::string, je dois logiquement inclure et <streambuf> et <string>. Or, il y a des implémentations où <streambuf> inclut <string> déjà, ce qui veut dire que si j'oublis <string>, l'en-tête va compiler quand même tout seul. Jusqu'à ce que je porte à une autre implémentation. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 Back to top Jean-Marc Bourguet Guest Posted: Thu Apr 08, 2004 7:44 am    Post subject: Re: Emplacement des #include [email]kanze (AT) gabi-soft (DOT) fr[/email] writes: Quote: Jean-Marc Bourguet <jm (AT) bourguet (DOT) org> wrote in message news:<pxbfzbf956y.fsf (AT) news (DOT) bourguet.org>... "Jean-Noël Mégoz" <nospam_jnmegoz (AT) infonie (DOT) fr> writes: La solution proposée ici est-elle équivalente/meilleure/la seule envisageable ? Il y a deux ecoles - ceux qui ne mettent aucun #include dans un .hxx - ceux qui considere qu'un fichier ne contenant que #include "foo.hxx" doit pouvoir compiler quel que soit foo.hxx Je fais partie de la seconde -- et plus je touche des projets ou des gens de la premiere ont sevi, plus je suis convaincu que ma position est la bonne. Je crois que de nos jours, il s'est fait un consensus pour la seconde. J'ai des collegues membres farouches de la premiere avec suffisemment d'autorite pour l'imposer dans leur projet. Heureusement ce n'est pas le mien... :-) Quote: Pour la reste, j'avoue ne jamais avoir eu à travailler avec du code de la première école. Quand ce n'était pas la seconde école, c'était à peu près n'importe quoi. Reellement n'importe quoi j'ai pas vu. Mais du code des gens de la premiere modifie par des gens qui n'ont pas pris l'initiative de passer clairement a la seconde, ca oui. Generalement j'ajoute alors les en-tetes qu'il faut a la premiere occasion. Quote: Ceci dit, ce n'est pas toujours évident à enforcer la seconde école. Pour prendre un exemple un peu bête, si j'écris une classe qui dérive de std::streambuf, et qui contient un membre de type std::string, je dois logiquement inclure et <streambuf> et string>. Or, il y a des implémentations où <streambuf> inclut string> déjà, ce qui veut dire que si j'oublis <string>, l'en-tête va compiler quand même tout seul. Jusqu'à ce que je porte à une autre implémentation. Tu peux avoir exactement le meme probleme en etant de la premiere ecole, a part que pour le fixer tu devras modifier 1234 fichiers. 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 Back to top Jan Rendek Guest Posted: Thu Apr 08, 2004 8:02 am    Post subject: Re: Emplacement des #include Quote: Mais par contre, la classe a besoin d'utiliser list (std::list ?), et j'ajouterai un #include <list>. Enfin, ce .h suppose l'utilisation d'un using namespace, ce qui est moche. Pour info, on est jamais obligé d'utiliser une directive 'using' pour exploiter des classes définies dans un namespace. Il suffit d'utiliser leur nom complet (std::list) dans ce cas. L'utilisation d'un 'using namespace XXX' dans un fichier d'entête n'est pas moche, elle est *à proscrire* absoluement. Back to top Fabien LE LEZ Guest Posted: Thu Apr 08, 2004 8:16 pm    Post subject: Re: Emplacement des #include On 8 Apr 2004 00:29:44 -0700, [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote: Quote: Ceci dit, ce n'est pas toujours évident à enforcer la seconde école. Pour prendre un exemple un peu bête, si j'écris une classe qui dérive de std::streambuf, et qui contient un membre de type std::string, je dois logiquement inclure et <streambuf> et <string>. Or, il y a des implémentations où <streambuf> inclut <string> déjà, ce qui veut dire que si j'oublis <string>, l'en-tête va compiler quand même tout seul. Jusqu'à ce que je porte à une autre implémentation. Pour le coup, il ne s'agit pas d'un problème d'école, juste d'un bug dans ton code, invisible sur cettains compilos. -- ;-) Back to top kanze@gabi-soft.fr Guest Posted: Tue Apr 13, 2004 10:45 am    Post subject: Re: Emplacement des #include Jean-Marc Bourguet <jm (AT) bourguet (DOT) org> wrote Quote: kanze (AT) gabi-soft (DOT) fr writes: Jean-Marc Bourguet <jm (AT) bourguet (DOT) org> wrote in message news:<pxbfzbf956y.fsf (AT) news (DOT) bourguet.org>... "Jean-Noël Mégoz" <nospam_jnmegoz (AT) infonie (DOT) fr> writes: La solution proposée ici est-elle équivalente/meilleure/la seule envisageable ? Il y a deux ecoles - ceux qui ne mettent aucun #include dans un .hxx - ceux qui considere qu'un fichier ne contenant que #include "foo.hxx" doit pouvoir compiler quel que soit foo.hxx Je fais partie de la seconde -- et plus je touche des projets ou des gens de la premiere ont sevi, plus je suis convaincu que ma position est la bonne. Je crois que de nos jours, il s'est fait un consensus pour la seconde. J'ai des collegues membres farouches de la premiere avec suffisemment d'autorite pour l'imposer dans leur projet. Heureusement ce n'est pas le mien... En effet. Dans les premiers jours de C, on pouvait encore en discuter. Mais avec un langage qui permet des membres privés et des fonctions inline ? Le profiler dit qu'il faut passer une fonction f() inline, et cette fonction utilise interne un en-tête qui n'était pas inclu avant. Et tu veux me dire qu'il y a des gens aujourd'hui pour dire encore qu'il faut retapper tous les utilisateurs de ta classe, pour ajouter l'include chez eux ? Quote: Pour la reste, j'avoue ne jamais avoir eu à travailler avec du code de la première école. Quand ce n'était pas la seconde école, c'était à peu près n'importe quoi. Reellement n'importe quoi j'ai pas vu. Mais du code des gens de la premiere modifie par des gens qui n'ont pas pris l'initiative de passer clairement a la seconde, ca oui. Generalement j'ajoute alors les en-tetes qu'il faut a la premiere occasion. Disons que ce sont en général des gens qui n'ont pas pensé à la question. Neuf fois sur dix, s'il voit que la classe X utilise l'en-tête Y, il vont l'inclure dans l'en-tête de la classe X. Mais ils n'y reflechit pas, et dans la mésure que ça compile dans leur programme de test (où ils ont bien inclut <string> avant), il y en a la moitié qui passe à côté. Je crois que Fabien a dit le mot juste. Si tu négliges un en-tête qu'il te faut logiquement, c'est une erreur de programmation, même si le code compile pour l'instant. Et si tu ne pars pas de ce principe (et tu utilises quand même les include dans les en-têtes), c'est à peu près n'importe quoi. Quote: Ceci dit, ce n'est pas toujours évident à enforcer la seconde école. Pour prendre un exemple un peu bête, si j'écris une classe qui dérive de std::streambuf, et qui contient un membre de type std::string, je dois logiquement inclure et <streambuf> et <string>. Or, il y a des implémentations où <streambuf> inclut <string> déjà, ce qui veut dire que si j'oublis <string>, l'en-tête va compiler quand même tout seul. Jusqu'à ce que je porte à une autre implémentation. Tu peux avoir exactement le meme probleme en etant de la premiere ecole, a part que pour le fixer tu devras modifier 1234 fichiers. Ce qui est, je crois, l'argument de base en faveur de la seconde école. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ (French) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.