Variable non utilisée dans macro

Bonjour.

Citation:

---

Envoyé par Josiane22

Du coup, je perd l'intéret de la chose puisque je compile des choses qui ne sont pas utiles... Et puis, mon programme est suffisamment compliqué, je n'ai pas trop envie de rajouter autant de ligne de code que de macro non utilisées...

---

Je ne sais pas quel compilateur tu utilises, mais un truc qui sert à rien dans le code sera occulté par le compilateur en mode release.

PS: à vérifier quand même au vu du static...

PS2: (c'est mon opinion à moi seul) les macros en tant que fonction c'est le mal absolu. C'est pas débuggable, c'est pas maintenable, c'est le bordel d'un compilateur à un autre, bref ça devrait pas exister (nous sommes des développeurs, pas des scripteurs). Il y a les templates, les inline, les forceinline, c'est exactement pareil et sans les défauts. De plus en tant que fonction inline ou template il n'y aurait plus ce warning...

PS3: (après lecture complète des messages) On te demande de retirer les warnings sans modifier le code en profondeur. Je pense que la prochaine étape sera de te demander que le logiciel fasse le café en changeant une seule ligne de code...
Tu dois expliquer que le père Noël n'existe pas...

PS4: Comme l'a signalé Bousk, sous visual studio tu as les #pragma warning. N'y a-t-il pas un équivalent sous gcc ?

Citation:

---

Envoyé par Bousk;7214374
Tu peux masquer le warning (c'est un simple pragma que [URL="https://www.google.com/search?q=hide+warning+message+C&aq=f&oq=hide+warning+message+C&aqs=chrome.0.57j0.7342j0&sourceid=chrome&ie=UTF-8"

Google te donnera en ~1s[/URL])
>> C'est je trouve un mauvais choix.

---

C'est un très mauvais choix en effet lorsque tu compiles ton projet à toi. Par contre lorsque tu compiles des projets tel que ffmpeg ou openframeworks, tu es vraiment content que ça existe.

Rebonjour,

Citation:

---

Envoyé par Josiane22

Tu pourrais m'expliquer un peu ce que fais cette ligne?

---

Laquelle ? Celle-là:

Code:

---

static double __attribute__((__unused__)) truc;

---

Citation:

---

Envoyé par Josiane22

De ce que j'ai compris, ca veux dire en gros "déclare truc mais attention, je sais que truc ne sera pas toujours utilisé. Donc ne me le signale pas à chaque fois...". c'est ça?

---

C'est exactement ça, voir ici

Citation:

---

Envoyé par Josiane22

Si oui, quelle différence entre ça et une option de compilation qui ne m'afficherais pas les warning.

---

La différence c'est que l'attribut ne s'applique qu'a la variable en question, et ne désactive le warning que pour ces variables, pas pour les variables qui ne sont pas marquées avec cet attribut. L'option de compilation, elle, désactivera ce warning pour toutes les variables.

Citation:

---

Envoyé par Josiane22

J'ai un peu peur de cacher mon problème au lieu de le supprimer

---

Toute la question est là, est-ce un problème ? Mais il me semble que ton but principal (compte tenu des contraintes que tu as) est justement de masquer ce problème pour pouvoir te concentrer sur les autres.

Pour revenir sur le pourquoi le programmeur a écrit un tel code:

Code:

---

1 2	static double truc; #define TOTO(a) ((truc=(a)) == 0.0 ? 0.0 : 2*truc)

---

Ça évite la répétition des effets de bords (voir cette FAQ C).
Note que pour ce problème, g++ offre une extension:

Code:

---

#define TOTO(a) ({ double truc=(a); truc == 0.0 ? 0.0 : 2*truc; })

---

(Voir ici.)

Cependant, la solution C++ à ce problème est d'utiliser des fonctions inline:

Code:

---

inline double TOTO(double a) {return a == 0.0 ? 0.0 : 2*a;}

---

(Les macros sont la solution C pour optimiser une « fonction » en supprimant l'appel de fonction, la solution C++ pour ça, c'est les fonctions inline.)
Cette solution, en plus d'être du C++, me paraît compatible avec ta contrainte « je dois apporter un minimum de changement » (après, ça dépend de la quantité de telles macros).

Citation:

---

Envoyé par nowahn

Cependant, la solution C++ à ce problème est d'utiliser des fonctions inline:

Code:

---

inline double TOTO(double a) {return a == 0.0 ? 0.0 : 2*a;}

---

(Les macros sont la solution C pour optimiser une « fonction » en supprimant l'appel de fonction, la solution C++ pour ça, c'est les fonctions inline.)
Cette solution, en plus d'être du C++, me paraît compatible avec ta contrainte « je dois apporter un minimum de changement » (après, ça dépend de la quantité de telles macros).

---

C++ ou pas, c'est le compilateur qui décidera au final s'il inline la méthode.
Donc la seule vraie solution pour "l'inliner" c'est la macro qui remplacera effectivement l'appel par le code de la fonction en question.