Preprocesseur, macro,test argument

Bonjour

j'ai une macro Macro(x) et voudrai faire un test sur argument (x) du style

Code:

---

1 2 3 4 5 6 7

#define Macro(x) #if ((x)==0) #error petit #elif ((x)>1000) #error grand #else développement ici de la macro qui a aussi des tests sur l'argument. #endif

---

Bien sur ci dessus ne fonctionne pas.Tout cela pour ne compiler que le code nécessaire.
J'ai cela mais compile tout et ne me convient pas car si 0 ou >1000 compile aussi, sans avertissement du préprocesseur

Code:

---

1 2 3 4 5 6

#define Macro(x)\ do{\ if ((x)>0)\ .... }\ while(0)

---

Si vous avez la solution, je suis bien sur preneur

Merci

Bonjour,
Je ne sais pas si tu l'as déjà lu, mais je te conseil ce document.
Tu pourras voir les limites des macros

Merci
Pour ta doc, doc que j'ai lu et tant d'autres.

La non compilation suite à un test , ce fait sur, les delays en C par exemple:

Code:

---

tempo.c:216: error: (1355) inline delay argument too large

---

j'ai bien la un arrêt de la compil suite à une valeur trop grande,avec inline,

Je peux me tromper, mais il doit bien y avoir une méthode pour extraire l' argument, bon il y à bien # mais le transforme en chaîne et le #if c'est sur un int.

je vais continu mes cherches,

Encore merci pour ta démarche

Citation:

---

Envoyé par Neratou

Je peux me tromper, mais il doit bien y avoir une méthode pour extraire l' argument, bon il y à bien # mais le transforme en chaîne et le #if c'est sur un int.

---

Hola , non c'est pas un int , les instruction préprocesseurs se font avant la compilation...
D'ailleurs c'est la tout le souci de ton code , tu peux pas écrire du code dans le préprocesseur comme tu le fat, si tu veux faire de l'optimisation avec des Macro alors utilise les inline ;)

Ou 'utilisr une macro comme ceci si c'est pour du petit code par exemple :

Code:

---

1 2	#define Macro(x) if(x == 1000){ a = 2;}else a = 3;

---

Sur plusieurs lignes :

Code:

---

1 2 3 4 5 6

#define Macro(x) \   if(x == 1000) \   a = 2; \   else \   a = 3;

---

Bonjour et merci de me répondre

j'ai bien utilisé ta proposition, probleme, c'est que tu compiles les 2 conditions avec un saut si condition 1 est vrai par exemple, et pas avertissement si >grand que ou ==0 comme le fait actuellement mon compil
j'ai aussi fait un test inline.
Problème, toujours si je trompe les fonctions inline ne font, pas appel à la pile, et donc elles ce comportent, comme des macros.Ici j'ai un joli appel à ma fonction inline avec un beau call, mais je vais gratter coté inline,pas normal

merci encore

PS: un bon tuto sur l'utilisation de inline

Pourquoi faire une macro et non une fonction (potentiellement inline) ?

Les macros c'est le mal dés que ça devient compliqué.

Comment vois-tu que la fonction n'est pas inlinée ?

bonjour et merci

Car je désassemble, le code. le compil est XC8 sous mplabx, en mode debug

Et tu pense sincèrement qu'une macro sera mieux?

Citation:

---

Envoyé par Neratou

bonjour et merci

Car je désassemble, le code. le compil est XC8 sous mplabx, en mode debug

---

Justement sur le forum C++ il y'a eu une discussion similaire , gcc avec l'option -O3 inline bien le code (le code assembleur est bien inliné ! ).

ok pour le fil et super pour asm

j'ai de nouveau fait un test inline voici le code de la la fonction

Code:

---

1 2 3 4

static inline test() { us_16() //marco }

---

c'est fonction qui appel une macro
et le résultat

Code:

---

1 2 3

! test(); 0x10BE: CALL 0x1BF2, 0 0x10C0: NOP

---

on voit bien que l'on appel un spg adresse 0x1BF2

et le spg

Code:

---

1 2 3 4 5 6 7

! us_16() //marco 0x1BF2: DECFSZ y, F, BANKED 0x1BF4: BRA __end_of_Init_Timer1 0x1BF6: DECFSZ 0x99, F, BANKED 0x1BF8: BRA 0x1BEC !} 0x1BFA: RETURN 0

---

Donc je vais voir le pourquoi il y probleme et suivre vos conseils utilisation de inline et revenir vers vous pour d'autres question sur inline

encore merci

Bon contact pour ma premier ici ;)

Citation:

---

Donc je vais voir le pourquoi il y probleme et suivre vos conseils utilisation de inline et revenir vers vous pour d'autres question sur inline

---

Le pourquoi du probleme ne dépend pas du langage , il dépend du compilateur si ton compilateur ne sait pas optimiser le inline y'a pas grand chose a faire ;)

Si ton code est vraiment petit , le code que je t'ai montré avec le define est suffisant.

NT: j'ai codé en asm sur des machines ayant quelque mhz et avec des instructions coûtant plusieurs cycle.
En gros un CALL/RET c'est quoi 4 cycle sur un AVR atmel , ça reste très correct surtout s'il est cadencé a 16 MHZ ou plus ;)
D'ailleurs même si en asm j'utilisais les macro j’évitai le full macro , la taille de l’exécutable devenait trop important.

Citation:

---

Envoyé par Kannagi

Le pourquoi du probleme ne dépend pas du langage , il dépend du compilateur si ton compilateur ne sait pas optimiser le inline y'a pas grand chose a faire ;)

---

OUI, c'est cela, en grattant un peu, c'est au bon vouloir du compil les inlines.et de plus j'ai la version free , pas d'optimisation affaire réglé ;)
Je vais donc rester avec mes defines et peaufiner mes boucles en ASM.
Car le probleme, sous xc8 (compil pour 8 bits) les delays ne sont pas terrible,tout comme les lib, donc on s'amuse, à refaire, je sais la roue........

Allez je vous remercie et vous dit à bientôt.

Citation:

---

Envoyé par Neratou

le compil est XC8 sous mplabx, en mode debug

---

Ah mais tu aurais dû nous dire ça plus tôt ! On t'aurait dit qu'on était désolé pour toi, qu'on te faisait des bisous et qu'on te souhaitait bonne chance ! :)

Ton assembleur ne parait étonnait. Si us_16() est une macro, on devrait voir son corps dans test() ; or ici on voit que ce n'est pas le cas. Je raisonne juste, si ta fonction n'était pas inlinée, tu verrais des CALL @addresse_de_test au lieu de voir le corps de test() dans l'assembleur. Quelque chose m'échappe...

Citation:

---

en grattant un peu, c'est au bon vouloir du compil les inlines

---

Oui. C'est une indication et non un ordre.

Citation:

---

et de plus j'ai la version free , pas d'optimisation affaire réglé

---

Je pense que ton vrai problème est là...