Bonjour,
Dans le bouquin de Ph. Drix ("Le langage C ANSI"), je trouve l'exemple
suivant pour illustrer les "substitutions réitérées" par le préprocesseur :
------------- 8< -------------------------------
#define w 0,1
#define f(x,y) (x)+(y)
f(w) /* est remplacé par (0)+(1) */
------------- >8 -------------------------------
Or, chez moi sur gcc, ça ne marche pas :
------------- 8< -------------------------------
:~$ gcc -E test.c
test.c:4:4: erreur: macro « f » requiert 2 arguments, mais seulement 1 ont
été passés
f
------------- >8 -------------------------------
Pourtant il me semble que l'exemple est valide, non ?
Bonjour,
Dans le bouquin de Ph. Drix ("Le langage C ANSI"), je trouve l'exemple
suivant pour illustrer les "substitutions réitérées" par le préprocesseur :
------------- 8< -------------------------------
#define w 0,1
#define f(x,y) (x)+(y)
f(w) /* est remplacé par (0)+(1) */
------------- >8 -------------------------------
Or, chez moi sur gcc, ça ne marche pas :
------------- 8< -------------------------------
candide@candide-desktop:~$ gcc -E test.c
test.c:4:4: erreur: macro « f » requiert 2 arguments, mais seulement 1 ont
été passés
f
------------- >8 -------------------------------
Pourtant il me semble que l'exemple est valide, non ?
Bonjour,
Dans le bouquin de Ph. Drix ("Le langage C ANSI"), je trouve l'exemple
suivant pour illustrer les "substitutions réitérées" par le préprocesseur :
------------- 8< -------------------------------
#define w 0,1
#define f(x,y) (x)+(y)
f(w) /* est remplacé par (0)+(1) */
------------- >8 -------------------------------
Or, chez moi sur gcc, ça ne marche pas :
------------- 8< -------------------------------
:~$ gcc -E test.c
test.c:4:4: erreur: macro « f » requiert 2 arguments, mais seulement 1 ont
été passés
f
------------- >8 -------------------------------
Pourtant il me semble que l'exemple est valide, non ?
Pourtant il me semble que l'exemple est valide, non ?
Non. La substitution de f se fait avant celle de ses arguments.
Pourtant il me semble que l'exemple est valide, non ?
Non. La substitution de f se fait avant celle de ses arguments.
Pourtant il me semble que l'exemple est valide, non ?
Non. La substitution de f se fait avant celle de ses arguments.
Je trouve que l'algorithme de preprocess et en particulier d'expansion
de macros n'est pas clairement expliqué en général.
Je trouve que l'algorithme de preprocess et en particulier d'expansion
de macros n'est pas clairement expliqué en général.
Je trouve que l'algorithme de preprocess et en particulier d'expansion
de macros n'est pas clairement expliqué en général.
Je trouve que l'algorithme de preprocess et en particulier d'expansion
de macros n'est pas clairement expliqué en général.
Qu'en pensez-vous ?
Je trouve que l'algorithme de preprocess et en particulier d'expansion
de macros n'est pas clairement expliqué en général.
Qu'en pensez-vous ?
Je trouve que l'algorithme de preprocess et en particulier d'expansion
de macros n'est pas clairement expliqué en général.
Qu'en pensez-vous ?
Par qui ? par les ouvrages d'enseignement du C : àmha, c'est parfaitement
voulu, car il est vain de vouloir écrire du code complètement portable si tu
joues avec cela : ce domaine a mis du temps à mûrir, donc les compilateurs
ont mis beaucoup de temps à se stabiliser, donc si tu joues trop sur les
bords tu vas trouver des cas où les compilateurs diffèrent, autrement dit le
code n'est pas portable. Comme le gain réel est faible ou nul (car le code
est difficile à comprendre pour un humain), ce n'est pas enseigné.
Par qui ? par les ouvrages d'enseignement du C : àmha, c'est parfaitement
voulu, car il est vain de vouloir écrire du code complètement portable si tu
joues avec cela : ce domaine a mis du temps à mûrir, donc les compilateurs
ont mis beaucoup de temps à se stabiliser, donc si tu joues trop sur les
bords tu vas trouver des cas où les compilateurs diffèrent, autrement dit le
code n'est pas portable. Comme le gain réel est faible ou nul (car le code
est difficile à comprendre pour un humain), ce n'est pas enseigné.
Par qui ? par les ouvrages d'enseignement du C : àmha, c'est parfaitement
voulu, car il est vain de vouloir écrire du code complètement portable si tu
joues avec cela : ce domaine a mis du temps à mûrir, donc les compilateurs
ont mis beaucoup de temps à se stabiliser, donc si tu joues trop sur les
bords tu vas trouver des cas où les compilateurs diffèrent, autrement dit le
code n'est pas portable. Comme le gain réel est faible ou nul (car le code
est difficile à comprendre pour un humain), ce n'est pas enseigné.
En news:47e26470$0$20187$, candide va escriure:Je trouve que l'algorithme de preprocess et en particulier d'expansion
de macros n'est pas clairement expliqué en général.
Par qui ? par les ouvrages d'enseignement du C :
àmha, c'est parfaitement
voulu, car il est vain de vouloir écrire du code complètement portable si tu
joues avec cela :
ce domaine a mis du temps à mûrir, donc les compilateurs
ont mis beaucoup de temps à se stabiliser, donc si tu joues trop sur les
bords tu vas trouver des cas où les compilateurs diffèrent, autrement dit le
code n'est pas portable.
Comme le gain réel est faible ou nul (car le code
est difficile à comprendre pour un humain), ce n'est pas enseigné.
D'abord et surtout que le résultat est le même !
Ensuite que les principaux préprocesseurs conformes semblent à première vue
pencher pour l'interprétation de MM. Harbison & Steele, mais je ne suis pas
assez calé en préprocesseur pour être capable d'expliquer clairement
pourquoi.
Ce qui me paraît clair, c'est que l'interprétation précise demande
l'intervention de spécialistes, donc tout code qui essaye de jouer au plus
fin
En news:47e26470$0$20187$426a74cc@news.free.fr, candide va escriure:
Je trouve que l'algorithme de preprocess et en particulier d'expansion
de macros n'est pas clairement expliqué en général.
Par qui ? par les ouvrages d'enseignement du C :
àmha, c'est parfaitement
voulu, car il est vain de vouloir écrire du code complètement portable si tu
joues avec cela :
ce domaine a mis du temps à mûrir, donc les compilateurs
ont mis beaucoup de temps à se stabiliser, donc si tu joues trop sur les
bords tu vas trouver des cas où les compilateurs diffèrent, autrement dit le
code n'est pas portable.
Comme le gain réel est faible ou nul (car le code
est difficile à comprendre pour un humain), ce n'est pas enseigné.
D'abord et surtout que le résultat est le même !
Ensuite que les principaux préprocesseurs conformes semblent à première vue
pencher pour l'interprétation de MM. Harbison & Steele, mais je ne suis pas
assez calé en préprocesseur pour être capable d'expliquer clairement
pourquoi.
Ce qui me paraît clair, c'est que l'interprétation précise demande
l'intervention de spécialistes, donc tout code qui essaye de jouer au plus
fin
En news:47e26470$0$20187$, candide va escriure:Je trouve que l'algorithme de preprocess et en particulier d'expansion
de macros n'est pas clairement expliqué en général.
Par qui ? par les ouvrages d'enseignement du C :
àmha, c'est parfaitement
voulu, car il est vain de vouloir écrire du code complètement portable si tu
joues avec cela :
ce domaine a mis du temps à mûrir, donc les compilateurs
ont mis beaucoup de temps à se stabiliser, donc si tu joues trop sur les
bords tu vas trouver des cas où les compilateurs diffèrent, autrement dit le
code n'est pas portable.
Comme le gain réel est faible ou nul (car le code
est difficile à comprendre pour un humain), ce n'est pas enseigné.
D'abord et surtout que le résultat est le même !
Ensuite que les principaux préprocesseurs conformes semblent à première vue
pencher pour l'interprétation de MM. Harbison & Steele, mais je ne suis pas
assez calé en préprocesseur pour être capable d'expliquer clairement
pourquoi.
Ce qui me paraît clair, c'est que l'interprétation précise demande
l'intervention de spécialistes, donc tout code qui essaye de jouer au plus
fin
Je rajouterai: lorsque j'enseigne le C, il y a des constructions que
j'apprend aux etudiants a utiliser, et d'autres constructions que je
leur apprend a lire.
Je garde generalement le preprocesseur pour assez tard, et je leur donne
les fonctions inline en meme temps. J'explique pourquoi le preprocesseur
est une mauvaise idee dans enormement de cas, et je donne les rares cas
d'utilisation `raisonnables' (voire indispensables):
- les constantes (dommage que C n'ait pas emprunte a C++ en la matiere)
- les #ifdef raisonnes (en expliquant la necessite de faire un niveau
d'indirection supplementaire pour avoir des #ifdef `feature-based' pour
les problemes de portabilite).
- quelques cas tres specifiques, dont __FILE__, __func__ (pas preprocesseur,
mais bon), et assert.
- #if 0 comme facon simple de commenter rapidement un bloc de code.
- les definitions de champs `simplifies' pour les union.
Pour le reste, je leur montre des exemples de code reel... le plus souvent
suffisamment moche pour ne pas donner envie.
Je rajouterai: lorsque j'enseigne le C, il y a des constructions que
j'apprend aux etudiants a utiliser, et d'autres constructions que je
leur apprend a lire.
Je garde generalement le preprocesseur pour assez tard, et je leur donne
les fonctions inline en meme temps. J'explique pourquoi le preprocesseur
est une mauvaise idee dans enormement de cas, et je donne les rares cas
d'utilisation `raisonnables' (voire indispensables):
- les constantes (dommage que C n'ait pas emprunte a C++ en la matiere)
- les #ifdef raisonnes (en expliquant la necessite de faire un niveau
d'indirection supplementaire pour avoir des #ifdef `feature-based' pour
les problemes de portabilite).
- quelques cas tres specifiques, dont __FILE__, __func__ (pas preprocesseur,
mais bon), et assert.
- #if 0 comme facon simple de commenter rapidement un bloc de code.
- les definitions de champs `simplifies' pour les union.
Pour le reste, je leur montre des exemples de code reel... le plus souvent
suffisamment moche pour ne pas donner envie.
Je rajouterai: lorsque j'enseigne le C, il y a des constructions que
j'apprend aux etudiants a utiliser, et d'autres constructions que je
leur apprend a lire.
Je garde generalement le preprocesseur pour assez tard, et je leur donne
les fonctions inline en meme temps. J'explique pourquoi le preprocesseur
est une mauvaise idee dans enormement de cas, et je donne les rares cas
d'utilisation `raisonnables' (voire indispensables):
- les constantes (dommage que C n'ait pas emprunte a C++ en la matiere)
- les #ifdef raisonnes (en expliquant la necessite de faire un niveau
d'indirection supplementaire pour avoir des #ifdef `feature-based' pour
les problemes de portabilite).
- quelques cas tres specifiques, dont __FILE__, __func__ (pas preprocesseur,
mais bon), et assert.
- #if 0 comme facon simple de commenter rapidement un bloc de code.
- les definitions de champs `simplifies' pour les union.
Pour le reste, je leur montre des exemples de code reel... le plus souvent
suffisamment moche pour ne pas donner envie.
- les constantes (dommage que C n'ait pas emprunte a C++ en la matiere)
et les enums ?
- les constantes (dommage que C n'ait pas emprunte a C++ en la matiere)
et les enums ?
- les constantes (dommage que C n'ait pas emprunte a C++ en la matiere)
et les enums ?
Je comprends pas : si les préprocesseurs sont conformes à la norme, il
ne devrait pas y avoir de différence.
Je comprends pas : si les préprocesseurs sont conformes à la norme, il
ne devrait pas y avoir de différence.
Je comprends pas : si les préprocesseurs sont conformes à la norme, il
ne devrait pas y avoir de différence.
In article <47e98121$0$3604$,
candide wrote:- les constantes (dommage que C n'ait pas emprunte a C++ en la matiere)
et les enums ?
A moitie pourries pour plein de raisons, entre autres parce qu'on ne sait pas
exactement a quel type elles correspondent.
In article <47e98121$0$3604$426a34cc@news.free.fr>,
candide <c.candide@free.fr> wrote:
- les constantes (dommage que C n'ait pas emprunte a C++ en la matiere)
et les enums ?
A moitie pourries pour plein de raisons, entre autres parce qu'on ne sait pas
exactement a quel type elles correspondent.
In article <47e98121$0$3604$,
candide wrote:- les constantes (dommage que C n'ait pas emprunte a C++ en la matiere)
et les enums ?
A moitie pourries pour plein de raisons, entre autres parce qu'on ne sait pas
exactement a quel type elles correspondent.