a propos du préprocesseur - Page 1

-

-

je me demandais si le préprocesseur etait super puissant dans gcc

genre, est ce qu'il optimiserait ceci:
#define Droite 0
#define Gauche 1

if(sens==Droite) { }

en:
if(!sens) { }
?

bah, le préprocesseur va transformer ton
if(sens==droite)
en
if(sens==0)

et ensuite, c au compilateur de l'optimiser.

idem, est ce qu'il effectue tout les calculs avant de compiler genre:
#define XSTART 20
#define YSTART 8 screen=myscreen+(XSTART*240)+(240-YSTART-16);

le préprocesseur remplace les valeurs... c'est ensuite au compilateur de faire les calculs, s'il le veut...
(perso, je considère que c'est le cas ; je n'hésite pas à mettre des calculs bien détaillés dans mes progs, en me disant que le compilateur calculera lui-même )

-

Le préprocesseur GNU marche comme prévu par le standard C, ce qui n'est pas vraiment le cas de celui de M$VC. Un token préprocesseur valide est soit:
* un opérateur
* un identifiant (lettre + suite de chiffres et de lettres)
* "nombre du préprocesseur" (chiffre + suite de chiffres et de lettres, et quelques cas particuliers avec ., e-, d-, e+ et d+). La définition est plus générale que celle d'un "nombre du compilateur" pour pouvoir les utiliser comme des morceaux d'identifiants dans les collages. Si à la fin, on n'obtient pas un "nombre du compilateur" ou un identifiant, on aura une erreur en compilant.
* une directive ('#' + suite de chiffres et de lettres)
(Dans tout ceci, '_' est considéré comme une lettre.)
Tout le reste n'est pas un token préprocesseur valide, et le préprocesseur n'est pas obligé d'accepter ça comme un token. Or, ## est censé produire un token, d'où ton erreur. Le ## est totalement inutile s'il s'agit de 2 tokens différents, donc vire-le.

-

-

sBibi
: VC++ accepte tout ce qui passe avec gcc (du moins tout ce que j'ai pu tester), par contre l'inverse non...

Peut-être que ça a été corrigé, mais le préprocesseur de M$ a longtemps été connu comme boguant complètement si on utilise certains features subtils du préprocesseur décrit par le standard C.

tu trouve ca logique toi qu'il ne veuille pas coller deux trucs comme ca:

toto. ## dtc

??

et qu'il lui faille:

toto. [espace] dtc
??

Oui, parce que toto.dtc n'est pas un token préprocesseur valide, ni même .dtc. Il y a 3 tokens ici.
Et l'espace n'est pas nécessaire. (Serait-ce un des cas subtils qui fait boguer M$VC?)

-

sBibi
: TRUC(...) ## _machin. ## TRUC2(...)

Code correct:
TRUC(...)##_machin.TRUC2(...)
## pour le premier parce qu'il y a vraiment concaténation, pas pour le deuxième où ce sont 2 tokens différents.

(a noter que le comportement du preprocesseur dans les trucs que j'essaye de lui filer change entre la V 2.qquechose et la V3.0)

Oui, le préprocesseur de GCC 2 avait quelques bogues qui ont été corrigés dans GCC 3.

et si j'ai envie de coller TRUC(...) ## -> ## TRUC2(...) avec gcc je peux pas?

Pourquoi tu veux le coller avec ##? Mets TRUC(...)->TRUC2(...) tout simplement.

-

-

Tu te compliques vachement la vie:
#define TOTO(a, b, c) (a c b)
suffit.

-

Moi, je trouve contre-intuitif et stupide de vouloir concaténér 2 tokens qui ne forment pas un token préprocesseur valide.

-

-

-

Euh j'ai pas trop regardé tes codes source, mais je confirme quand même ce que dit Kevin : tu n'as vraiment pas besoin de coller un . et un identificateur : tu peux parfaitement écrire "my_expression . member" avec des espaces et ça donnera le même résultat que "my_expression.member", donc tu n'as pas besoin de ##/GLUE/etc dans ce cas-là. Par contre, si tu veux écrire l'identificateur "foobar", tu n'obtiendrais pas le même résultat en tapant "foo bar" : c'est donc que tu as besoin de ##. En gros, ne mets jamais de ## si un espace suffit, ou en tout cas pas si tu veux faire du code portable.

(PS : le préprocesseur de GTC accepte ça sans problème, donc je dis ça en toute impartialité, hein Kevin )

-

Tu peux utiliser des définitions différentes de la même. Ça te fera un seul endroit à changer.

#ifdef USE_UNDERSCORE
#define TRUC(a,b) a##_##b
#else
#ifdef USE_DOT
#define TRUC(a,b) a.b
#else
#define TRUC(a,b) a->b
#endif
#endif

Quant à ton code source, il est très simple à corriger: tu supprimes tous les usages de ##, ils sont tous faux et complètement inutiles. J'ai l'impression que tu n'as pas du tout compris à quoi sert la concaténation de tokens. Clairement pas à supprimer quelques espaces dans le résultat du préprocesseur que pratiquement personne ne lit!

Pollux
: tu peux parfaitement écrire "my_expression . member" avec des espaces

Même sans espaces. Que les espaces soient là ou pas, ce sont des tokens séparés, donc l'expansion de macros est appliquée.

-

le truc c'est juste que j'aimerai comprendre QUEL est l'interet de limiter volontairement de cette facon?! ca sert a rien merde... en tout cas si ca sert j'aimerai bien qu'on me dise a quoi...

Bah, le préprocesseur peut travailler sur des tokens ou sur du texte, au choix. S'il travaille sur des tokens (comme GCC), alors ça va être difficile de lui faire gober un ## entre deux tokens de types différents. Et ce n'est _généralement_ pas un problème, puisqu'on peut faire tout ce qu'on veut *au niveau du code C généré* -- je ne parle pas de l'aspect cosmétique, mais uniquement sémantique.

et justement si, je fais certains (c) des collages pour supprimer les espaces dans le fichier d'output du preprocesseur... pour que ces macros produisent du code semblable a ce qu'il y a ailleurs... (edit: uniquement point de vue presentation) c'est interdit peut etre?

Ben voilà, ton problème est là. Le préprocesseur C n'a pas été conçu pour faire de la "présentation", mais juste pour être donné en pâture à un compilo, donc il peut rajouter 50 espaces si ça lui fait plaisir. Tu peux toujours tenter de faire de la présentation avec si tu y tiens, mais en tout cas ne t'étonne pas quant à la portabilité de la chose. Si ça ne marche pas comme tu voudrais, tu ne peux t'en prendre qu'à toi-même.

-

Quand on préprocesse et compile en même temps, les tokens peuvent être passés directement au parser, ce qui accélère la compilation. C'est ce qui, à ma connaissance, va se passer de plus en plus avec GCC. C'est pour ça que tu as ce warning, qui est désormais une erreur depuis GCC 3.3.

bon bah voila... merci g ma reponse (enfin )
donc c'est pour accelerer la compilation... donc c'est dmc...

et ya pas moyen de faire marcher le truc du post 21 avec le preprocesseur de gcc?
c'est merdique... perso je prefere une compil un peu plus lente mais avec une gestion de ce genre de macros...

Tu coupes tes fichiers source en plusieurs suivant chacun une convention, et tu utilises la méthode des #ifdef.
Ou alors, plus sale, tu réinclus le header à chaque fois que la convention a changé.
Ou encore, tu utilises 2 ou 3 macros, un avec chaque convention.

oue mais la ca perd tout l'interet de la chose
bon tant pis... v me demmerder sans... ca sera encore plus crade mais bon...