On Mon, 23 May 2005 11:31:10 +0200, Bruno CAUSSE :
Est il correcte de placer les directives #include après les "ifndef" dans les fichiers d'entete?
Oui : ça permet de n'avoir pas à ouvrir ces fichiers #inclus inutilement.
Existe t'il une convention d'écriture de code?
Sur ce point ? Je ne sais pas, mais quant à moi, j'écris toujours le #ifndef/#define au tout début du .h, et le #endif correspond à la fin. Seuls des commentaires ont le droit de ne pas se trouver entre les deux.
Pourquoi puis je utiliser std::string sans directive #include<string>
Il est peut-être inclus indirectement ?
(compilo gcc)?
Quelle version ?
On Mon, 23 May 2005 11:31:10 +0200, Bruno CAUSSE <envoi@lesSpam.fr>:
Est il correcte de placer les directives #include après les "ifndef" dans
les fichiers d'entete?
Oui : ça permet de n'avoir pas à ouvrir ces fichiers #inclus
inutilement.
Existe t'il une convention d'écriture de code?
Sur ce point ? Je ne sais pas, mais quant à moi, j'écris toujours le
#ifndef/#define au tout début du .h, et le #endif correspond à la fin.
Seuls des commentaires ont le droit de ne pas se trouver entre les
deux.
Pourquoi puis je utiliser std::string sans directive
#include<string>
On Mon, 23 May 2005 11:31:10 +0200, Bruno CAUSSE :
Est il correcte de placer les directives #include après les "ifndef" dans les fichiers d'entete?
Oui : ça permet de n'avoir pas à ouvrir ces fichiers #inclus inutilement.
Existe t'il une convention d'écriture de code?
Sur ce point ? Je ne sais pas, mais quant à moi, j'écris toujours le #ifndef/#define au tout début du .h, et le #endif correspond à la fin. Seuls des commentaires ont le droit de ne pas se trouver entre les deux.
Pourquoi puis je utiliser std::string sans directive #include<string>
Il est peut-être inclus indirectement ?
(compilo gcc)?
Quelle version ?
Jean-Marc Bourguet
Bruno CAUSSE writes:
Bonjour,
Est il correcte de placer les directives #include après les "ifndef" dans les fichiers d'entete?
Si tu parles des gardes d'inclusion, oui. Sinon, je ne comprends pas la question.
Existe t'il une convention d'écriture de code?
Supplement :-) : Pourquoi puis je utiliser std::string sans directive #include<string> (compilo gcc)?
Tu inclus un autre en-tete qui inclus <string>, ce qui est autorise mais pas obligatoire, donc tu vas manquer de portabilite, peut-etre meme a une autre version de gcc.
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
Bruno CAUSSE <envoi@lesSpam.fr> writes:
Bonjour,
Est il correcte de placer les directives #include après les "ifndef" dans
les fichiers d'entete?
Si tu parles des gardes d'inclusion, oui. Sinon, je ne comprends pas
la question.
Existe t'il une convention d'écriture de code?
Supplement :-) : Pourquoi puis je utiliser std::string sans directive
#include<string> (compilo gcc)?
Tu inclus un autre en-tete qui inclus <string>, ce qui est autorise
mais pas obligatoire, donc tu vas manquer de portabilite, peut-etre
meme a une autre version de gcc.
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
Est il correcte de placer les directives #include après les "ifndef" dans les fichiers d'entete?
Si tu parles des gardes d'inclusion, oui. Sinon, je ne comprends pas la question.
Existe t'il une convention d'écriture de code?
Supplement :-) : Pourquoi puis je utiliser std::string sans directive #include<string> (compilo gcc)?
Tu inclus un autre en-tete qui inclus <string>, ce qui est autorise mais pas obligatoire, donc tu vas manquer de portabilite, peut-etre meme a une autre version de gcc.
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
Bruno CAUSSE
dans l'article , Fabien LE LEZ à a écrit le 23/05/05 11:43 :
Est il correcte de placer les directives #include après les "ifndef" dans les fichiers d'entete?
Oui : ça permet de n'avoir pas à ouvrir ces fichiers #inclus inutilement.
Donc dans le fichier XXXX.cpp je ne repete pas les includes apres #include "XXXX.h"
Existe t'il une convention d'écriture de code?
Sur ce point ? Je ne sais pas, mais quant à moi, j'écris toujours le #ifndef/#define au tout début du .h, et le #endif correspond à la fin. Seuls des commentaires ont le droit de ne pas se trouver entre les deux.
Pourquoi puis je utiliser std::string sans directive #include<string>
Il est peut-être inclus indirectement ?
Alors ds <iostream> seul fichier #inclus
"Fainéant " :-) : comment visualiser le contenu de ces fichiers.
(compilo gcc)?
Quelle version ? 3.3
dans l'article 4b9391pjalm2qeb69njv7rf3jdn1n325i6@4ax.com, Fabien LE LEZ à
gramster@gramster.com a écrit le 23/05/05 11:43 :
Est il correcte de placer les directives #include après les "ifndef" dans
les fichiers d'entete?
Oui : ça permet de n'avoir pas à ouvrir ces fichiers #inclus
inutilement.
Donc dans le fichier XXXX.cpp je ne repete pas les includes apres #include
"XXXX.h"
Existe t'il une convention d'écriture de code?
Sur ce point ? Je ne sais pas, mais quant à moi, j'écris toujours le
#ifndef/#define au tout début du .h, et le #endif correspond à la fin.
Seuls des commentaires ont le droit de ne pas se trouver entre les
deux.
Pourquoi puis je utiliser std::string sans directive
#include<string>
Il est peut-être inclus indirectement ?
Alors ds <iostream> seul fichier #inclus
"Fainéant " :-) : comment visualiser le contenu de ces fichiers.
dans l'article , Fabien LE LEZ à a écrit le 23/05/05 11:43 :
Est il correcte de placer les directives #include après les "ifndef" dans les fichiers d'entete?
Oui : ça permet de n'avoir pas à ouvrir ces fichiers #inclus inutilement.
Donc dans le fichier XXXX.cpp je ne repete pas les includes apres #include "XXXX.h"
Existe t'il une convention d'écriture de code?
Sur ce point ? Je ne sais pas, mais quant à moi, j'écris toujours le #ifndef/#define au tout début du .h, et le #endif correspond à la fin. Seuls des commentaires ont le droit de ne pas se trouver entre les deux.
Pourquoi puis je utiliser std::string sans directive #include<string>
Il est peut-être inclus indirectement ?
Alors ds <iostream> seul fichier #inclus
"Fainéant " :-) : comment visualiser le contenu de ces fichiers.
(compilo gcc)?
Quelle version ? 3.3
Fabien LE LEZ
On Mon, 23 May 2005 11:55:50 +0200, Bruno CAUSSE :
"Fainéant " :-) : comment visualiser le contenu de ces fichiers.
Ben... Chez moi, c'est clic droit -> Textpad. Ou, quand je suis dans l'IDE de BC++ 5.02, Ctrl+O puis a.
On Mon, 23 May 2005 11:55:50 +0200, Bruno CAUSSE <envoi@lesSpam.fr>:
"Fainéant " :-) : comment visualiser le contenu de ces fichiers.
Ben... Chez moi, c'est clic droit -> Textpad.
Ou, quand je suis dans l'IDE de BC++ 5.02, Ctrl+O puis a.
dans l'article , Fabien LE LEZ à a écrit le 23/05/05 12:08 :
Ben... Chez moi, c'est clic droit -> Textpad. Ou, quand je suis dans l'IDE de BC++ 5.02, Ctrl+O puis a.
Bon ok :-) je vais chercher. Chez moi c'est Xcode 1.5 ;-)
Michel Michaud
Dans le message BEB77546.4106%,
dans l'article , Fabien LE LEZ à a écrit le 23/05/05 11:43 :
Est il correcte de placer les directives #include après les "ifndef" dans les fichiers d'entete?
Oui : ça permet de n'avoir pas à ouvrir ces fichiers #inclus inutilement.
Donc dans le fichier XXXX.cpp je ne repete pas les includes apres #include "XXXX.h"
Après ? Peut-être, voir plus loin.
Existe t'il une convention d'écriture de code?
Je crois que la plupart des programmeurs C++ respectent la règle qui dit qu'un fichier d'en-tête doit être complet, donc contenir les #include qui sont nécessaires pour le code qu'il contient. Donc on devrait pouvoir compiler un fichier source qui ne fait qu'un include sur ce fichier.
Par contre, dans un fichier source, on ne compte pas sur un #include pour inclure accidentellement les autres #include dont on a vraiment besoin : si le fichier source utilise des string par exemple, on inclura explicitement <string> même si on a déjà inclus un autre fichier qui l'a (peut-être) inclus.
[...]
Pourquoi puis je utiliser std::string sans directive #include<string>
Il est peut-être inclus indirectement ?
Alors ds <iostream> seul fichier #inclus
Peut-être, mais tu devrais quand même faire le #include sur string explicitement... Un autre compilateur ou une autre version du compilateur pourrait ne pas faire inclure <string> par iostream.
"Fainéant " :-) : comment visualiser le contenu de ces fichiers.
Tu ne veux pas te fier là-dessus pour décider des includes à faire... En principe, <iostream> n'est peut-être pas un fichier et n'est peut-être pas visualisable...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message BEB77546.4106%envoi@lesSpam.fr,
dans l'article 4b9391pjalm2qeb69njv7rf3jdn1n325i6@4ax.com, Fabien
LE LEZ à gramster@gramster.com a écrit le 23/05/05 11:43 :
Est il correcte de placer les directives #include après les
"ifndef" dans les fichiers d'entete?
Oui : ça permet de n'avoir pas à ouvrir ces fichiers #inclus
inutilement.
Donc dans le fichier XXXX.cpp je ne repete pas les includes apres
#include "XXXX.h"
Après ? Peut-être, voir plus loin.
Existe t'il une convention d'écriture de code?
Je crois que la plupart des programmeurs C++ respectent la règle qui
dit qu'un fichier d'en-tête doit être complet, donc contenir les
#include qui sont nécessaires pour le code qu'il contient. Donc on
devrait pouvoir compiler un fichier source qui ne fait qu'un include
sur ce fichier.
Par contre, dans un fichier source, on ne compte pas sur un #include
pour inclure accidentellement les autres #include dont on a vraiment
besoin : si le fichier source utilise des string par exemple, on
inclura explicitement <string> même si on a déjà inclus un autre
fichier qui l'a (peut-être) inclus.
[...]
Pourquoi puis je utiliser std::string sans directive
#include<string>
Il est peut-être inclus indirectement ?
Alors ds <iostream> seul fichier #inclus
Peut-être, mais tu devrais quand même faire le #include sur string
explicitement... Un autre compilateur ou une autre version du
compilateur pourrait ne pas faire inclure <string> par iostream.
"Fainéant " :-) : comment visualiser le contenu de ces fichiers.
Tu ne veux pas te fier là-dessus pour décider des includes à faire...
En principe, <iostream> n'est peut-être pas un fichier et n'est
peut-être pas visualisable...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
dans l'article , Fabien LE LEZ à a écrit le 23/05/05 11:43 :
Est il correcte de placer les directives #include après les "ifndef" dans les fichiers d'entete?
Oui : ça permet de n'avoir pas à ouvrir ces fichiers #inclus inutilement.
Donc dans le fichier XXXX.cpp je ne repete pas les includes apres #include "XXXX.h"
Après ? Peut-être, voir plus loin.
Existe t'il une convention d'écriture de code?
Je crois que la plupart des programmeurs C++ respectent la règle qui dit qu'un fichier d'en-tête doit être complet, donc contenir les #include qui sont nécessaires pour le code qu'il contient. Donc on devrait pouvoir compiler un fichier source qui ne fait qu'un include sur ce fichier.
Par contre, dans un fichier source, on ne compte pas sur un #include pour inclure accidentellement les autres #include dont on a vraiment besoin : si le fichier source utilise des string par exemple, on inclura explicitement <string> même si on a déjà inclus un autre fichier qui l'a (peut-être) inclus.
[...]
Pourquoi puis je utiliser std::string sans directive #include<string>
Il est peut-être inclus indirectement ?
Alors ds <iostream> seul fichier #inclus
Peut-être, mais tu devrais quand même faire le #include sur string explicitement... Un autre compilateur ou une autre version du compilateur pourrait ne pas faire inclure <string> par iostream.
"Fainéant " :-) : comment visualiser le contenu de ces fichiers.
Tu ne veux pas te fier là-dessus pour décider des includes à faire... En principe, <iostream> n'est peut-être pas un fichier et n'est peut-être pas visualisable...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Bruno CAUSSE
dans l'article 0plke.2182$, Michel Michaud à a écrit le 23/05/05 16:03 :
Je crois que la plupart des programmeurs C++ respectent la règle qui dit qu'un fichier d'en-tête doit être complet, donc contenir les #include qui sont nécessaires pour le code qu'il contient. Donc on devrait pouvoir compiler un fichier source qui ne fait qu'un include sur ce fichier.
bon regle 1 : c'est clair. Ex : Un include utile seulement dans le cpp est inclus dans l'entete, apres le ifndef....
Par contre, dans un fichier source, on ne compte pas sur un #include pour inclure accidentellement les autres #include dont on a vraiment besoin : si le fichier source utilise des string par exemple, on inclura explicitement <string> même si on a déjà inclus un autre fichier qui l'a (peut-être) inclus.
Heu... regle 2 : moins clair. En supplement (complement) de la regle 1
Peut-être, mais tu devrais quand même faire le #include sur string explicitement... Un autre compilateur ou une autre version du compilateur pourrait ne pas faire inclure <string> par iostream.
Ok.
dans l'article 0plke.2182$Ot6.316057@news20.bellglobal.com, Michel Michaud à
mm@gdzid.com a écrit le 23/05/05 16:03 :
Je crois que la plupart des programmeurs C++ respectent la règle qui
dit qu'un fichier d'en-tête doit être complet, donc contenir les
#include qui sont nécessaires pour le code qu'il contient. Donc on
devrait pouvoir compiler un fichier source qui ne fait qu'un include
sur ce fichier.
bon regle 1 : c'est clair. Ex : Un include utile seulement dans le cpp est
inclus dans l'entete, apres le ifndef....
Par contre, dans un fichier source, on ne compte pas sur un #include
pour inclure accidentellement les autres #include dont on a vraiment
besoin : si le fichier source utilise des string par exemple, on
inclura explicitement <string> même si on a déjà inclus un autre
fichier qui l'a (peut-être) inclus.
Heu... regle 2 : moins clair. En supplement (complement) de la regle 1
Peut-être, mais tu devrais quand même faire le #include sur string
explicitement... Un autre compilateur ou une autre version du
compilateur pourrait ne pas faire inclure <string> par iostream.
dans l'article 0plke.2182$, Michel Michaud à a écrit le 23/05/05 16:03 :
Je crois que la plupart des programmeurs C++ respectent la règle qui dit qu'un fichier d'en-tête doit être complet, donc contenir les #include qui sont nécessaires pour le code qu'il contient. Donc on devrait pouvoir compiler un fichier source qui ne fait qu'un include sur ce fichier.
bon regle 1 : c'est clair. Ex : Un include utile seulement dans le cpp est inclus dans l'entete, apres le ifndef....
Par contre, dans un fichier source, on ne compte pas sur un #include pour inclure accidentellement les autres #include dont on a vraiment besoin : si le fichier source utilise des string par exemple, on inclura explicitement <string> même si on a déjà inclus un autre fichier qui l'a (peut-être) inclus.
Heu... regle 2 : moins clair. En supplement (complement) de la regle 1
Peut-être, mais tu devrais quand même faire le #include sur string explicitement... Un autre compilateur ou une autre version du compilateur pourrait ne pas faire inclure <string> par iostream.
Ok.
Marc Boyer
In article <BEB7B84F.414F%, Bruno CAUSSE wrote:
dans l'article 0plke.2182$, Michel Michaud à a écrit le 23/05/05 16:03 :
Je crois que la plupart des programmeurs C++ respectent la règle qui dit qu'un fichier d'en-tête doit être complet, donc contenir les #include qui sont nécessaires pour le code qu'il contient. Donc on devrait pouvoir compiler un fichier source qui ne fait qu'un include sur ce fichier.
bon regle 1 : c'est clair. Ex : Un include utile seulement dans le cpp est inclus dans l'entete, apres le ifndef....
Non, non: si un include n'est nécessaire que pour le cpp, il est dans le cpp.
Je pense que ce que Michel veut te dire, c'est qu'on écrit
Comme pour compiler la /signature/ de foo, il faut string, c'est le module toto qui se charge de l'inclure, on demande pas à l'utilisateur de faire un #include <string> s'il veut faire #include "toto.hpp".
Après, si toto.cpp a besoin de map, c'est toto.cpp qui fait #include <map>, pas toto.hpp.
Par contre, dans un fichier source, on ne compte pas sur un #include pour inclure accidentellement les autres #include dont on a vraiment besoin : si le fichier source utilise des string par exemple, on inclura explicitement <string> même si on a déjà inclus un autre fichier qui l'a (peut-être) inclus.
Heu... regle 2 : moins clair. En supplement (complement) de la regle 1
Si dans mon module titi, j'utilise foo (de toto) et des std::string, je fais un #include de toto.hpp et de string.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
In article <BEB7B84F.414F%envoi@lesSpam.fr>, Bruno CAUSSE wrote:
dans l'article 0plke.2182$Ot6.316057@news20.bellglobal.com, Michel Michaud à
mm@gdzid.com a écrit le 23/05/05 16:03 :
Je crois que la plupart des programmeurs C++ respectent la règle qui
dit qu'un fichier d'en-tête doit être complet, donc contenir les
#include qui sont nécessaires pour le code qu'il contient. Donc on
devrait pouvoir compiler un fichier source qui ne fait qu'un include
sur ce fichier.
bon regle 1 : c'est clair. Ex : Un include utile seulement dans le cpp est
inclus dans l'entete, apres le ifndef....
Non, non: si un include n'est nécessaire que pour le cpp,
il est dans le cpp.
Je pense que ce que Michel veut te dire, c'est qu'on écrit
Comme pour compiler la /signature/ de foo, il faut string,
c'est le module toto qui se charge de l'inclure, on demande
pas à l'utilisateur de faire un #include <string> s'il veut
faire #include "toto.hpp".
Après, si toto.cpp a besoin de map, c'est toto.cpp qui fait
#include <map>, pas toto.hpp.
Par contre, dans un fichier source, on ne compte pas sur un #include
pour inclure accidentellement les autres #include dont on a vraiment
besoin : si le fichier source utilise des string par exemple, on
inclura explicitement <string> même si on a déjà inclus un autre
fichier qui l'a (peut-être) inclus.
Heu... regle 2 : moins clair. En supplement (complement) de la regle 1
Si dans mon module titi, j'utilise foo (de toto) et des
std::string, je fais un #include de toto.hpp et de string.
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
dans l'article 0plke.2182$, Michel Michaud à a écrit le 23/05/05 16:03 :
Je crois que la plupart des programmeurs C++ respectent la règle qui dit qu'un fichier d'en-tête doit être complet, donc contenir les #include qui sont nécessaires pour le code qu'il contient. Donc on devrait pouvoir compiler un fichier source qui ne fait qu'un include sur ce fichier.
bon regle 1 : c'est clair. Ex : Un include utile seulement dans le cpp est inclus dans l'entete, apres le ifndef....
Non, non: si un include n'est nécessaire que pour le cpp, il est dans le cpp.
Je pense que ce que Michel veut te dire, c'est qu'on écrit
Comme pour compiler la /signature/ de foo, il faut string, c'est le module toto qui se charge de l'inclure, on demande pas à l'utilisateur de faire un #include <string> s'il veut faire #include "toto.hpp".
Après, si toto.cpp a besoin de map, c'est toto.cpp qui fait #include <map>, pas toto.hpp.
Par contre, dans un fichier source, on ne compte pas sur un #include pour inclure accidentellement les autres #include dont on a vraiment besoin : si le fichier source utilise des string par exemple, on inclura explicitement <string> même si on a déjà inclus un autre fichier qui l'a (peut-être) inclus.
Heu... regle 2 : moins clair. En supplement (complement) de la regle 1
Si dans mon module titi, j'utilise foo (de toto) et des std::string, je fais un #include de toto.hpp et de string.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Bruno CAUSSE
dans l'article d6sqk8$jrp$, Marc Boyer à a écrit le 23/05/05 16:50 :
Non, non:
Bon deuxieme essai :-)
Dans hpp tout les includes necessaires au hpp. (apres #ifndef)
Dans cpp tout les includes necessaires au cpp sauf ceux du hpp correspondant.
dans l'article d6sqk8$jrp$1@news.cict.fr, Marc Boyer à
Marc.Boyer@enseeiht.yahoo.fr.invalid a écrit le 23/05/05 16:50 :
Non, non:
Bon deuxieme essai :-)
Dans hpp tout les includes necessaires au hpp. (apres #ifndef)
Dans cpp tout les includes necessaires au cpp sauf ceux du hpp
correspondant.
