dans le cadre d'un projet en C assez important, où on défini plusieurs
fichier.h définissant des types, incluant des bibliothèques etc... je
cherche des infos sur comment organiser tout ça au mieux pour ne pas que ça
devienne le souk au bout d'un certain temps avec des include par ici,
d'autres définitions par là... des trucs qui se croisent dans tous les sens
etc...
faut-il par exemple y aller a gros coup de
#ifndef CONSTANTE
#define CONSTANTE
dans le cadre d'un projet en C assez important, où on défini plusieurs fichier.h définissant des types, incluant des bibliothèques etc... je cherche des infos sur comment organiser tout ça au mieux pour ne pas que ça devienne le souk au bout d'un certain temps avec des include par ici, d'autres définitions par là... des trucs qui se croisent dans tous les sens etc...
faut-il par exemple y aller a gros coup de #ifndef CONSTANTE #define CONSTANTE
a chaque fois qu'on inclu une bibliothèque ??
La methode utilisee generalement consiste a verifier si le fichier a deja ete inclus.
Par exemple dans biblio.h
/* en tete du fichier */
#ifndef BIBLIO_H #define BIBLIO_H
/* ici le contenu du fichier */
/* et en fin : */
#endif
Et si tu veux gerer des inclusions de fichiers dans des fichiers inclus (il y a du pour et du contre...) tu peux en profiter pour eviter d'inclure un fichier s'il la deja ete, pour simplifier la tache au compilateur.
Dans biblio2.h, qui a besoin de types/constantes dans biblio.h
/* en tete du fichier */
#ifndef BIBLIO2_H #define BIBLIO2_H
/* les inclusions necessaires */
#ifndef BIBLIO_H #include "biblio.h" #endif
/* ici le contenu du fichier */
/* et en fin : */
#endif
salut,
dans le cadre d'un projet en C assez important, où on défini plusieurs
fichier.h définissant des types, incluant des bibliothèques etc... je
cherche des infos sur comment organiser tout ça au mieux pour ne pas que ça
devienne le souk au bout d'un certain temps avec des include par ici,
d'autres définitions par là... des trucs qui se croisent dans tous les sens
etc...
faut-il par exemple y aller a gros coup de
#ifndef CONSTANTE
#define CONSTANTE
a chaque fois qu'on inclu une bibliothèque ??
La methode utilisee generalement consiste a verifier si le fichier a deja ete
inclus.
Par exemple dans biblio.h
/* en tete du fichier */
#ifndef BIBLIO_H
#define BIBLIO_H
/* ici le contenu du fichier */
/* et en fin : */
#endif
Et si tu veux gerer des inclusions de fichiers dans des fichiers inclus
(il y a du pour et du contre...)
tu peux en profiter pour eviter d'inclure un fichier s'il la deja ete, pour
simplifier la tache au compilateur.
Dans biblio2.h, qui a besoin de types/constantes dans biblio.h
dans le cadre d'un projet en C assez important, où on défini plusieurs fichier.h définissant des types, incluant des bibliothèques etc... je cherche des infos sur comment organiser tout ça au mieux pour ne pas que ça devienne le souk au bout d'un certain temps avec des include par ici, d'autres définitions par là... des trucs qui se croisent dans tous les sens etc...
faut-il par exemple y aller a gros coup de #ifndef CONSTANTE #define CONSTANTE
a chaque fois qu'on inclu une bibliothèque ??
La methode utilisee generalement consiste a verifier si le fichier a deja ete inclus.
Par exemple dans biblio.h
/* en tete du fichier */
#ifndef BIBLIO_H #define BIBLIO_H
/* ici le contenu du fichier */
/* et en fin : */
#endif
Et si tu veux gerer des inclusions de fichiers dans des fichiers inclus (il y a du pour et du contre...) tu peux en profiter pour eviter d'inclure un fichier s'il la deja ete, pour simplifier la tache au compilateur.
Dans biblio2.h, qui a besoin de types/constantes dans biblio.h
/* en tete du fichier */
#ifndef BIBLIO2_H #define BIBLIO2_H
/* les inclusions necessaires */
#ifndef BIBLIO_H #include "biblio.h" #endif
/* ici le contenu du fichier */
/* et en fin : */
#endif
Emmanuel Delahaye
In 'fr.comp.lang.c', "Nicolas aunai" @free.fr> wrote:
salut,
dans le cadre d'un projet en C assez important, où on défini plusieurs fichier.h définissant des types, incluant des bibliothèques etc... je cherche des infos sur comment organiser tout ça au mieux pour ne pas que ça devienne le souk au bout d'un certain temps avec des include par ici, d'autres définitions par là... des trucs qui se croisent dans tous les sens etc...
faut-il par exemple y aller a gros coup de #ifndef CONSTANTE #define CONSTANTE
a chaque fois qu'on inclu une bibliothèque ??
Non, surtout qu'il y a d'autres façon de définir une constante (enum, par exemple).
Par contre, la démarche de découpage du projet (conception) doit être claire, de façon à ce que chaque module représente une entitée fonctionelle autonome.
Le cas simple :
Un module (x.c) un header (x.h)
Ce header doit être inclus dans le x.c et dans tous les .c qui l'utilisent.
Ce header doit être protégé contre les inclusions multiples:
#ifndef H_X #define H_X
/* x.h */
/* reste des definitions de constantes et de type * et des declarations de fonctions et d'ojets. */
#endif /* guard */
Un cas plus complexe : le bloc fonctionnel X est compose de plusieurs unité de compilations
/* xa.c */ /* xb.c */ /* xc.c */
Dans ce cas, il est conseillé de séparer les fonctions publiques en
- points d'entrée du module (à déclarer dans le "x.h") - fonctions publiques internes (à declarer dans un fichier d'entete "x_i.h")
"x_i.h" est inclus dans chaque x*.c. Il inclus aussi "x.h"
Par contre, c'est "x.h" qui est publié, et non "x_i.h".
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', "Nicolas aunai" <nicolas.aunai@nospam@free.fr> wrote:
salut,
dans le cadre d'un projet en C assez important, où on défini plusieurs
fichier.h définissant des types, incluant des bibliothèques etc... je
cherche des infos sur comment organiser tout ça au mieux pour ne pas que ça
devienne le souk au bout d'un certain temps avec des include par ici,
d'autres définitions par là... des trucs qui se croisent dans tous les sens
etc...
faut-il par exemple y aller a gros coup de
#ifndef CONSTANTE
#define CONSTANTE
a chaque fois qu'on inclu une bibliothèque ??
Non, surtout qu'il y a d'autres façon de définir une constante (enum, par
exemple).
Par contre, la démarche de découpage du projet (conception) doit être claire,
de façon à ce que chaque module représente une entitée fonctionelle autonome.
Le cas simple :
Un module (x.c) un header (x.h)
Ce header doit être inclus dans le x.c et dans tous les .c qui l'utilisent.
Ce header doit être protégé contre les inclusions multiples:
#ifndef H_X
#define H_X
/* x.h */
/* reste des definitions de constantes et de type
* et des declarations de fonctions et d'ojets.
*/
#endif /* guard */
Un cas plus complexe : le bloc fonctionnel X est compose de plusieurs unité
de compilations
/* xa.c */
/* xb.c */
/* xc.c */
Dans ce cas, il est conseillé de séparer les fonctions publiques en
- points d'entrée du module (à déclarer dans le "x.h")
- fonctions publiques internes (à declarer dans un fichier d'entete "x_i.h")
"x_i.h" est inclus dans chaque x*.c. Il inclus aussi "x.h"
Par contre, c'est "x.h" qui est publié, et non "x_i.h".
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', "Nicolas aunai" @free.fr> wrote:
salut,
dans le cadre d'un projet en C assez important, où on défini plusieurs fichier.h définissant des types, incluant des bibliothèques etc... je cherche des infos sur comment organiser tout ça au mieux pour ne pas que ça devienne le souk au bout d'un certain temps avec des include par ici, d'autres définitions par là... des trucs qui se croisent dans tous les sens etc...
faut-il par exemple y aller a gros coup de #ifndef CONSTANTE #define CONSTANTE
a chaque fois qu'on inclu une bibliothèque ??
Non, surtout qu'il y a d'autres façon de définir une constante (enum, par exemple).
Par contre, la démarche de découpage du projet (conception) doit être claire, de façon à ce que chaque module représente une entitée fonctionelle autonome.
Le cas simple :
Un module (x.c) un header (x.h)
Ce header doit être inclus dans le x.c et dans tous les .c qui l'utilisent.
Ce header doit être protégé contre les inclusions multiples:
#ifndef H_X #define H_X
/* x.h */
/* reste des definitions de constantes et de type * et des declarations de fonctions et d'ojets. */
#endif /* guard */
Un cas plus complexe : le bloc fonctionnel X est compose de plusieurs unité de compilations
/* xa.c */ /* xb.c */ /* xc.c */
Dans ce cas, il est conseillé de séparer les fonctions publiques en
- points d'entrée du module (à déclarer dans le "x.h") - fonctions publiques internes (à declarer dans un fichier d'entete "x_i.h")
"x_i.h" est inclus dans chaque x*.c. Il inclus aussi "x.h"
Par contre, c'est "x.h" qui est publié, et non "x_i.h".
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
serait encore plus conseillé pour détecter les conflits de versions en cas de cafouillage :)
J'ai du rater quelque chose: j'arrive pas à voir en quoi le fait d'ajouter la date va permettre de détecter quoi que ce soit. Tu peux donner un exemple de config ou cela sert ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
In article <oprsvh20sctkqod2@news.free.fr>, leneuf22 wrote:
serait encore plus conseillé pour détecter les conflits de versions en cas
de cafouillage :)
J'ai du rater quelque chose: j'arrive pas à voir en quoi le
fait d'ajouter la date va permettre de détecter quoi que ce soit.
Tu peux donner un exemple de config ou cela sert ?
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
serait encore plus conseillé pour détecter les conflits de versions en cas de cafouillage :)
J'ai du rater quelque chose: j'arrive pas à voir en quoi le fait d'ajouter la date va permettre de détecter quoi que ce soit. Tu peux donner un exemple de config ou cela sert ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Marc Boyer
In article , Yves ROMAN wrote:
Et si tu veux gerer des inclusions de fichiers dans des fichiers inclus (il y a du pour et du contre...) tu peux en profiter pour eviter d'inclure un fichier s'il la deja ete, pour simplifier la tache au compilateur.
Quel intérêt Que ça compile plus vite ? Ca me semble surtout source d'erreurs, non ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
In article <3F2152FC.C106E504@unilog.fr>, Yves ROMAN wrote:
Et si tu veux gerer des inclusions de fichiers dans des fichiers inclus
(il y a du pour et du contre...)
tu peux en profiter pour eviter d'inclure un fichier s'il la deja ete, pour
simplifier la tache au compilateur.
Quel intérêt
Que ça compile plus vite ?
Ca me semble surtout source d'erreurs, non ?
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Et si tu veux gerer des inclusions de fichiers dans des fichiers inclus (il y a du pour et du contre...) tu peux en profiter pour eviter d'inclure un fichier s'il la deja ete, pour simplifier la tache au compilateur.
Quel intérêt Que ça compile plus vite ? Ca me semble surtout source d'erreurs, non ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
AG
J'ai du rater quelque chose: j'arrive pas à voir en quoi le fait d'ajouter la date va permettre de détecter quoi que ce soit. Tu peux donner un exemple de config ou cela sert ?
j'ai jamais fait ça, mais j'imagine :
t'as un nouveau header, avec un nouveau prototype de fonction dedans. tu l'inclues dans le projet, tu compiles, et le compilo te dis que le prototype de cette fonction n'existe pas. Tu comprends pas parce que pourtant t'as bien inclu le nouveau header.
En fait, t'as aussi inclu le header de la version précédante, et comme ils ont le même garde fous
#ifndef HEADER_XXX_H #define HEADER_XXX_H
le deuxième n'est pas pris en compte puisqu'ils ont le même garde fou. Ceci n'arrivera jamais si tu mets la date dans le garde fou.
Evidamment, ça n'arrive pas non plus si tu es sur de ne jamais inclure deux versions d'un même fichier en même temps, etc...
J'ai du rater quelque chose: j'arrive pas à voir en quoi le
fait d'ajouter la date va permettre de détecter quoi que ce soit.
Tu peux donner un exemple de config ou cela sert ?
j'ai jamais fait ça, mais j'imagine :
t'as un nouveau header, avec un nouveau prototype de fonction dedans.
tu l'inclues dans le projet, tu compiles, et le compilo te dis que le
prototype de cette fonction n'existe pas. Tu comprends pas parce que
pourtant t'as bien inclu le nouveau header.
En fait, t'as aussi inclu le header de la version précédante, et comme
ils ont le même garde fous
#ifndef HEADER_XXX_H
#define HEADER_XXX_H
le deuxième n'est pas pris en compte puisqu'ils ont le même garde fou.
Ceci n'arrivera jamais si tu mets la date dans le garde fou.
Evidamment, ça n'arrive pas non plus si tu es sur de ne jamais inclure
deux versions d'un même fichier en même temps, etc...
J'ai du rater quelque chose: j'arrive pas à voir en quoi le fait d'ajouter la date va permettre de détecter quoi que ce soit. Tu peux donner un exemple de config ou cela sert ?
j'ai jamais fait ça, mais j'imagine :
t'as un nouveau header, avec un nouveau prototype de fonction dedans. tu l'inclues dans le projet, tu compiles, et le compilo te dis que le prototype de cette fonction n'existe pas. Tu comprends pas parce que pourtant t'as bien inclu le nouveau header.
En fait, t'as aussi inclu le header de la version précédante, et comme ils ont le même garde fous
#ifndef HEADER_XXX_H #define HEADER_XXX_H
le deuxième n'est pas pris en compte puisqu'ils ont le même garde fou. Ceci n'arrivera jamais si tu mets la date dans le garde fou.
Evidamment, ça n'arrive pas non plus si tu es sur de ne jamais inclure deux versions d'un même fichier en même temps, etc...
Yves ROMAN
In article , Yves ROMAN wrote:
Et si tu veux gerer des inclusions de fichiers dans des fichiers inclus (il y a du pour et du contre...) tu peux en profiter pour eviter d'inclure un fichier s'il la deja ete, pour simplifier la tache au compilateur.
Quel intérêt Que ça compile plus vite ?
Oui : pour éviter au précompilateur de parser 3000 fois un même fichier pour rien
Ca me semble surtout source d'erreurs, non ?
Effectivement, car il faut savoir, a l'extérieur du fichier, le nom de la constante utilisée a l'intérieur du fichier. Cela nécessite une nomenclature rigide.
In article <3F2152FC.C106E504@unilog.fr>, Yves ROMAN wrote:
Et si tu veux gerer des inclusions de fichiers dans des fichiers inclus
(il y a du pour et du contre...)
tu peux en profiter pour eviter d'inclure un fichier s'il la deja ete, pour
simplifier la tache au compilateur.
Quel intérêt
Que ça compile plus vite ?
Oui : pour éviter au précompilateur de parser 3000 fois un même fichier pour
rien
Ca me semble surtout source d'erreurs, non ?
Effectivement, car il faut savoir, a l'extérieur du fichier, le nom de la
constante utilisée a l'intérieur du fichier. Cela nécessite une nomenclature
rigide.
Et si tu veux gerer des inclusions de fichiers dans des fichiers inclus (il y a du pour et du contre...) tu peux en profiter pour eviter d'inclure un fichier s'il la deja ete, pour simplifier la tache au compilateur.
Quel intérêt Que ça compile plus vite ?
Oui : pour éviter au précompilateur de parser 3000 fois un même fichier pour rien
Ca me semble surtout source d'erreurs, non ?
Effectivement, car il faut savoir, a l'extérieur du fichier, le nom de la constante utilisée a l'intérieur du fichier. Cela nécessite une nomenclature rigide.
AG
Mais si tu mets la date, avec un peu de malchance, tu vas inclure les deux headers et ne t'appercevoir de rien.
Normalement, si tu redéfinis une structure, le compilo te le dis. Donc tu devrais t'en appercevoir (j'ai pas d'exemple en tête ou ça poserais un problème indétectable). Si tu ne t'en apperçois pas, c'est qu'il n'y a pas de conflit. Donc t'ajoutes du code qui n'est pas utilisé, mais c'est toujours mieux qu'un code qui ne compile pas.
Mais si tu mets la date, avec un peu de malchance, tu vas inclure
les deux headers et ne t'appercevoir de rien.
Normalement, si tu redéfinis une structure, le compilo te le dis. Donc
tu devrais t'en appercevoir (j'ai pas d'exemple en tête ou ça poserais
un problème indétectable). Si tu ne t'en apperçois pas, c'est qu'il n'y
a pas de conflit. Donc t'ajoutes du code qui n'est pas utilisé, mais
c'est toujours mieux qu'un code qui ne compile pas.
Mais si tu mets la date, avec un peu de malchance, tu vas inclure les deux headers et ne t'appercevoir de rien.
Normalement, si tu redéfinis une structure, le compilo te le dis. Donc tu devrais t'en appercevoir (j'ai pas d'exemple en tête ou ça poserais un problème indétectable). Si tu ne t'en apperçois pas, c'est qu'il n'y a pas de conflit. Donc t'ajoutes du code qui n'est pas utilisé, mais c'est toujours mieux qu'un code qui ne compile pas.
Marc Boyer
In article , AG wrote:
Marc Boyer wrote:
Compile sans un message d'erreur ou avertissement (avec gcc -Wall -c fclc.c -pedantic) Dans ce cas, tu redéfinis deux fois la même chose, ce n'est pas très
grave. Que dit lint à ce sujet ?
Pas de définition, mais une déclaration, ce qui fait toute la différence. Et j'ai pas de lint..
Pour moi, inclure deux versions distinctes du même header par erreur, c'est une erreur grave de conception, et il vaut mieux la détecter à la compilation. Certes. Ne pas inclure la date dans le garde fou est-il le meilleur
moyen pour cela ?
Non.
Si non, inclure la date dans les gardes fous n'offre-t-il pas des avantages ?
Lesquels ? Hormis une surcharge de travail (la mise à jour à chaque modif), je ne vois pas.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
In article <3F250429.2080101@tb.fr>, AG wrote:
Marc Boyer wrote:
Compile sans un message d'erreur ou avertissement
(avec gcc -Wall -c fclc.c -pedantic)
Dans ce cas, tu redéfinis deux fois la même chose, ce n'est pas très
grave. Que dit lint à ce sujet ?
Pas de définition, mais une déclaration, ce qui fait
toute la différence.
Et j'ai pas de lint..
Pour moi, inclure deux versions distinctes du même header
par erreur, c'est une erreur grave de conception, et il
vaut mieux la détecter à la compilation.
Certes. Ne pas inclure la date dans le garde fou est-il le meilleur
moyen pour cela ?
Non.
Si non, inclure la date dans les gardes fous n'offre-t-il pas des
avantages ?
Lesquels ?
Hormis une surcharge de travail (la mise à jour à chaque modif),
je ne vois pas.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Compile sans un message d'erreur ou avertissement (avec gcc -Wall -c fclc.c -pedantic) Dans ce cas, tu redéfinis deux fois la même chose, ce n'est pas très
grave. Que dit lint à ce sujet ?
Pas de définition, mais une déclaration, ce qui fait toute la différence. Et j'ai pas de lint..
Pour moi, inclure deux versions distinctes du même header par erreur, c'est une erreur grave de conception, et il vaut mieux la détecter à la compilation. Certes. Ne pas inclure la date dans le garde fou est-il le meilleur
moyen pour cela ?
Non.
Si non, inclure la date dans les gardes fous n'offre-t-il pas des avantages ?
Lesquels ? Hormis une surcharge de travail (la mise à jour à chaque modif), je ne vois pas.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Marc Boyer
Yves ROMAN wrote:
In article , Yves ROMAN wrote:
Et si tu veux gerer des inclusions de fichiers dans des fichiers inclus (il y a du pour et du contre...) tu peux en profiter pour eviter d'inclure un fichier s'il la deja ete, pour simplifier la tache au compilateur.
Quel intérêt Que ça compile plus vite ?
Oui : pour éviter au précompilateur de parser 3000 fois un même fichier pour rien
Huuh... Avec le même genre d'argument, on enlève les commentaires (ça fatigue le préprocesseur) et on choisit des noms de variable de moins de 3 lettres pour ne pas surcharger la table des symboles.
Soyons sérieux.
Ca me semble surtout source d'erreurs, non ?
Effectivement, car il faut savoir, a l'extérieur du fichier, le nom de la constante utilisée a l'intérieur du fichier. Cela nécessite une nomenclature rigide.
Et on brise plein de beaux principes d'encapsulation.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Yves ROMAN wrote:
In article <3F2152FC.C106E504@unilog.fr>, Yves ROMAN wrote:
Et si tu veux gerer des inclusions de fichiers dans des fichiers inclus
(il y a du pour et du contre...)
tu peux en profiter pour eviter d'inclure un fichier s'il la deja ete, pour
simplifier la tache au compilateur.
Quel intérêt
Que ça compile plus vite ?
Oui : pour éviter au précompilateur de parser 3000 fois un même fichier pour
rien
Huuh...
Avec le même genre d'argument, on enlève les commentaires (ça fatigue
le préprocesseur) et on choisit des noms de variable de moins de 3 lettres
pour ne pas surcharger la table des symboles.
Soyons sérieux.
Ca me semble surtout source d'erreurs, non ?
Effectivement, car il faut savoir, a l'extérieur du fichier, le nom de la
constante utilisée a l'intérieur du fichier. Cela nécessite une nomenclature
rigide.
Et on brise plein de beaux principes d'encapsulation.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Et si tu veux gerer des inclusions de fichiers dans des fichiers inclus (il y a du pour et du contre...) tu peux en profiter pour eviter d'inclure un fichier s'il la deja ete, pour simplifier la tache au compilateur.
Quel intérêt Que ça compile plus vite ?
Oui : pour éviter au précompilateur de parser 3000 fois un même fichier pour rien
Huuh... Avec le même genre d'argument, on enlève les commentaires (ça fatigue le préprocesseur) et on choisit des noms de variable de moins de 3 lettres pour ne pas surcharger la table des symboles.
Soyons sérieux.
Ca me semble surtout source d'erreurs, non ?
Effectivement, car il faut savoir, a l'extérieur du fichier, le nom de la constante utilisée a l'intérieur du fichier. Cela nécessite une nomenclature rigide.
Et on brise plein de beaux principes d'encapsulation.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
