D=E9butant pratiquant le C assidument depuis un peu plus de deux ans, il
m'arrive de me ponger dans le code d'applications libres dans un but
d'auto-formation. Il y a une chose qui me pose =E9norm=E9ment de
probl=E8mes (j'en ai m=EAme mal =E0 la t=EAte), c'est l'utilisation massive
de la compilation conditionnelle.
Comment faites-vous, lorsque vous avez =E0 maintenir un code en C qui
vous n'avez pas =E9crit vous-m=EAme (je pense que cela arrive souvent),
lorsque vous =EAtes face =E0 une suite de #ifdef ... #endif, etc. Y
a-t'il un moyen de conna=EEtre (via une commande de GCC) les constantes
du pr=E9processeur qui sont d=E9finies =E0 une certain moment du
programme? Un des objetctif cl=E9 de la compilation conditionnelle
semble =EAtre la portabilit=E9 multi-plateforme. Y a-t'il un moyen simple
de conna=EEtres les constantes du pr=E9-processeur qui sont d=E9finies par
d=E9faut sur ma plateforme? (J'ai un PC avec processeur PIII qui tourne
sous Linux Debian SID avec GCC 4.0.2)
En ce qui concerne la pratique courante pour =E9crire du code lisible...
Conseilleriez-vous de limiter l'usage de la compilation conditionnelle?
Tout cela, c'est des pr=E9occupations de d=E9butant, mais votre avis
m'interesse beaucoup, et vos conseils seront appr=E9ci=E9s =E0 leur juste
valeur! Meilleures salutations
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Anthony Fleury
Bonjour à tous,
Bonjour,
Comment faites-vous, lorsque vous avez à maintenir un code en C qui vous n'avez pas écrit vous-même (je pense que cela arrive souvent), lorsque vous êtes face à une suite de #ifdef ... #endif, etc. Y a-t'il un moyen de connaître (via une commande de GCC) les constantes du préprocesseur qui sont définies à une certain moment du programme? Un des objetctif clé de la compilation conditionnelle semble être la portabilité multi-plateforme. Y a-t'il un moyen simple de connaîtres les constantes du pré-processeur qui sont définies par défaut sur ma plateforme? (J'ai un PC avec processeur PIII qui tourne sous Linux Debian SID avec GCC 4.0.2)
Avec les options -E et -dM de gcc. -E arrête la compilation après le passage par le préprocesseur. Le fichier de sortie est donc un fichier qui est déjà traité par celui ci (inclusion, modification avec les #defines etc... effectués.
-E Run only the C preprocessor. Preprocess all the C source files specified and output the results to standard output or to the specified output file.
-dM nous donne lui l'ensemble des constantes de préprocesseur définies après traitement du fichier :
-dM Tell the preprocessor to output only a list of the macro definitions that are in effect at the end of preprocessing. Used with the `-E ' option.
Attention toutefois. Un source peut-être compilé en fonction de ce que le makefile définit. Suivant par exemple le résultat de la commande uname, un makefile peut définir les constantes à utiliser (options -Dmacro[=Valeur] et -dNmacro).
En ce qui concerne la pratique courante pour écrire du code lisible... Conseilleriez-vous de limiter l'usage de la compilation conditionnelle?
Dans beaucoup de cas, je ne vois pas bien comment l'éviter... Alors la lisibilité à côté, on l'ignore. Pour ma part (mais je ne suis pas non plus à classer parmis les professionnels), j'évite au maximum l'utilisation du préprocesseur.
-- Anthony Fleury
Bonjour à tous,
Bonjour,
Comment faites-vous, lorsque vous avez à maintenir un code en C qui
vous n'avez pas écrit vous-même (je pense que cela arrive souvent),
lorsque vous êtes face à une suite de #ifdef ... #endif, etc. Y
a-t'il un moyen de connaître (via une commande de GCC) les constantes
du préprocesseur qui sont définies à une certain moment du
programme? Un des objetctif clé de la compilation conditionnelle
semble être la portabilité multi-plateforme. Y a-t'il un moyen simple
de connaîtres les constantes du pré-processeur qui sont définies par
défaut sur ma plateforme? (J'ai un PC avec processeur PIII qui tourne
sous Linux Debian SID avec GCC 4.0.2)
Avec les options -E et -dM de gcc. -E arrête la compilation après le
passage par le préprocesseur. Le fichier de sortie est donc un fichier
qui est déjà traité par celui ci (inclusion, modification avec les
#defines etc... effectués.
-E
Run only the C preprocessor. Preprocess all the C source files
specified and output the results to standard output or to the specified
output file.
-dM nous donne lui l'ensemble des constantes de préprocesseur définies
après traitement du fichier :
-dM
Tell the preprocessor to output only a list of the macro
definitions that are in effect at the end of preprocessing. Used with
the `-E ' option.
Attention toutefois. Un source peut-être compilé en fonction de ce que
le makefile définit. Suivant par exemple le résultat de la commande
uname, un makefile peut définir les constantes à utiliser (options
-Dmacro[=Valeur] et -dNmacro).
En ce qui concerne la pratique courante pour écrire du code lisible...
Conseilleriez-vous de limiter l'usage de la compilation conditionnelle?
Dans beaucoup de cas, je ne vois pas bien comment l'éviter... Alors la
lisibilité à côté, on l'ignore. Pour ma part (mais je ne suis pas non
plus à classer parmis les professionnels), j'évite au maximum
l'utilisation du préprocesseur.
Comment faites-vous, lorsque vous avez à maintenir un code en C qui vous n'avez pas écrit vous-même (je pense que cela arrive souvent), lorsque vous êtes face à une suite de #ifdef ... #endif, etc. Y a-t'il un moyen de connaître (via une commande de GCC) les constantes du préprocesseur qui sont définies à une certain moment du programme? Un des objetctif clé de la compilation conditionnelle semble être la portabilité multi-plateforme. Y a-t'il un moyen simple de connaîtres les constantes du pré-processeur qui sont définies par défaut sur ma plateforme? (J'ai un PC avec processeur PIII qui tourne sous Linux Debian SID avec GCC 4.0.2)
Avec les options -E et -dM de gcc. -E arrête la compilation après le passage par le préprocesseur. Le fichier de sortie est donc un fichier qui est déjà traité par celui ci (inclusion, modification avec les #defines etc... effectués.
-E Run only the C preprocessor. Preprocess all the C source files specified and output the results to standard output or to the specified output file.
-dM nous donne lui l'ensemble des constantes de préprocesseur définies après traitement du fichier :
-dM Tell the preprocessor to output only a list of the macro definitions that are in effect at the end of preprocessing. Used with the `-E ' option.
Attention toutefois. Un source peut-être compilé en fonction de ce que le makefile définit. Suivant par exemple le résultat de la commande uname, un makefile peut définir les constantes à utiliser (options -Dmacro[=Valeur] et -dNmacro).
En ce qui concerne la pratique courante pour écrire du code lisible... Conseilleriez-vous de limiter l'usage de la compilation conditionnelle?
Dans beaucoup de cas, je ne vois pas bien comment l'éviter... Alors la lisibilité à côté, on l'ignore. Pour ma part (mais je ne suis pas non plus à classer parmis les professionnels), j'évite au maximum l'utilisation du préprocesseur.
-- Anthony Fleury
Harpo
wrote:
(...)
Je ne sais pas répondre à la première question de manière très utile.
(J'ai un PC avec processeur PIII qui tourne sous Linux Debian SID avec GCC 4.0.2)
Excellent ! Merci quand même de dire 'GNU/Linux'.
En ce qui concerne la pratique courante pour écrire du code lisible... Conseilleriez-vous de limiter l'usage de la compilation conditionnelle? Tout cela, c'est des préoccupations de débutant, mais votre avis m'interesse beaucoup, et vos conseils seront appréciés à leur juste valeur!
C'est vrai que les codes pleins de #ifdef sont difficiles à lire, surtout quand les #endif sont loin des #if. Personnellement, je recours à la stratégie suivante qui sera plus facilement comprise par un exemple.
Plutôt que de parsemer le code de : #ifdef HAVE_FOO y = foo( x ); #else y = bar( x ); #endif
Je mets; y = blurb( x );
et dans un .h, je mets :
#ifdef HAVE_FOO #define blurb( x ) foo( x ) #else #define blurb( x ) bar( x ) #endif
Cela sépare les 2 langages, celui du macro-processeur et celui du C proprement dit, même si cela ne réduit pas la complexité, cela évite de l'éparpiller et de fatiguer les yeux.
Evidemment, dans la pratique ce n'est pas toujours si simple mais cela permet de mieux appréhender la complexité.
-- http://harpo.free.fr/
thierry@mujigka.ch wrote:
(...)
Je ne sais pas répondre à la première question de manière très utile.
(J'ai un PC avec processeur PIII qui tourne
sous Linux Debian SID avec GCC 4.0.2)
Excellent ! Merci quand même de dire 'GNU/Linux'.
En ce qui concerne la pratique courante pour écrire du code lisible...
Conseilleriez-vous de limiter l'usage de la compilation
conditionnelle? Tout cela, c'est des préoccupations de débutant, mais
votre avis m'interesse beaucoup, et vos conseils seront appréciés à
leur juste valeur!
C'est vrai que les codes pleins de #ifdef sont difficiles à lire,
surtout quand les #endif sont loin des #if.
Personnellement, je recours à la stratégie suivante qui sera plus
facilement comprise par un exemple.
Plutôt que de parsemer le code de :
#ifdef HAVE_FOO
y = foo( x );
#else
y = bar( x );
#endif
Je mets;
y = blurb( x );
et dans un .h, je mets :
#ifdef HAVE_FOO
#define blurb( x ) foo( x )
#else
#define blurb( x ) bar( x )
#endif
Cela sépare les 2 langages, celui du macro-processeur et celui du C
proprement dit, même si cela ne réduit pas la complexité, cela évite de
l'éparpiller et de fatiguer les yeux.
Evidemment, dans la pratique ce n'est pas toujours si simple mais cela
permet de mieux appréhender la complexité.
Je ne sais pas répondre à la première question de manière très utile.
(J'ai un PC avec processeur PIII qui tourne sous Linux Debian SID avec GCC 4.0.2)
Excellent ! Merci quand même de dire 'GNU/Linux'.
En ce qui concerne la pratique courante pour écrire du code lisible... Conseilleriez-vous de limiter l'usage de la compilation conditionnelle? Tout cela, c'est des préoccupations de débutant, mais votre avis m'interesse beaucoup, et vos conseils seront appréciés à leur juste valeur!
C'est vrai que les codes pleins de #ifdef sont difficiles à lire, surtout quand les #endif sont loin des #if. Personnellement, je recours à la stratégie suivante qui sera plus facilement comprise par un exemple.
Plutôt que de parsemer le code de : #ifdef HAVE_FOO y = foo( x ); #else y = bar( x ); #endif
Je mets; y = blurb( x );
et dans un .h, je mets :
#ifdef HAVE_FOO #define blurb( x ) foo( x ) #else #define blurb( x ) bar( x ) #endif
Cela sépare les 2 langages, celui du macro-processeur et celui du C proprement dit, même si cela ne réduit pas la complexité, cela évite de l'éparpiller et de fatiguer les yeux.
Evidemment, dans la pratique ce n'est pas toujours si simple mais cela permet de mieux appréhender la complexité.
-- http://harpo.free.fr/
thierry
Merci beaucoup pour ta réponse!
Je vais essayer d'avancer avec les option -E et -dM du préprocesseur en mettant mon nez dans le makefile.
Meilleures salutations
Thierry
Merci beaucoup pour ta réponse!
Je vais essayer d'avancer avec les option -E et -dM du préprocesseur
en mettant mon nez dans le makefile.
