Variable non utilisée dans macro

Version imprimable

03/04/2013, 15h35
Josiane22

Variable non utilisée dans macro
Bonjour,

J'ai récupéré un code qui contient des macros. Ces macros introduisent une variable qui est déclaré juste au dessus. Exemple:
Code:

1 2 3 4 5 #ifndef TOTO static double truc; #define TOTO(a) ((truc=(a)) == 0.0 ? 0.0 : 2*truc) //on est d'accord ca a pas trop d'interet mais ce n'est qu'un exmple #endif
Le problème c'est que toutes les macros ne sont pas utilisées, mais sont quand même définies (j'ai un doute sur le vocabulaire). Disons qu'on rentre bien dans la macro, mais que dans le code, il n'y a nul part TOTO(bidule).

Ca amène donc à la compilation un warning du genre: "Eh, t'as déclaré truc mais tu l'as pas utilisé". Je peux comprendre ce qui le chagrine mais je voudrais supprimer ce warning. J'ai quand meme le droit de dire ce que fera ma macro TOTO si jamais on l'utilise sans pour autant devoir l'utiliser à tous les coups derrière...:roll:

Auriez-vous donc une astuce? (je ne veux pas par contre d'options de compil' qui cacheraient le warning. Je veux le supprimer.)
03/04/2013, 15h39
ternel

il suffit de l'utiliser.
au moins une fois.
Pour ce faire, dans le main, tu peux ajouter (void)truc;
03/04/2013, 15h46
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...
03/04/2013, 16h13
ternel

tu ne les utilises pas, ne les défini pas.
ca doit être possible, quitte à placer les defines dans un fichier autonome
03/04/2013, 16h29
Josiane22

Dans certains cas d'études, je serais amener à utiliser ces macros. J'ai donc pour contrainte de les définir même si pour l'instant ça ne sert visiblement à rien.
C'est bien là le problème. S'il s'agissait simplement de supprimer ce dont je ne me sert pas, je n'aurais pas posté la question ici ;)

Un autre exemple concret qui montre bien l'interet de définir les macros:
Celles-ci se trouve dans un .h. Dans ce .h, je fais appel à TOTO (avec TOTO(bidule)). Là pas de soucis, ma variable truc est déclarée et utilisée. Par contre, j'ai en plus de ça un .cpp, qui contient l'appel à une autre macro (qu'on va appelé TATA) et qui est elle aussi définie dans le .h juste à coté de TOTO.
J'ai donc bien sur un include<...h> en haut de mon .cpp. Mais là, chose étrange, j'ai quand même un warning qui me dis "hep, la variable tructata que tu as défini pour ta macro TATA, tu l'as défini dans ton .h, mais tu l'as pas utilisée!!!"

Pourtant elle est utilisé dans mon .cpp... Ca me fait quand même un warning. Et là, je ne peux pas supprimer la macro comme tu le suggère, sinon, dans mon .cpp, je vais faire appel à TATA mais sans l'avoir définie auparavant. Ca risque de moins bien marcher...
03/04/2013, 16h45
droggo

Joa,

Habituellement, la solution est d'encadrer ton #ifndef par un autre, de niveau supérieur.

Il n'est pas rare d'avoir ainsi plusieurs niveaux de conditions de compilation. :)
03/04/2013, 16h57
Josiane22

hello,

Qu'est ce qui pourrait controler le fait que je rentre ou non dans ce nouveau #ifndef? Une condition sur le fait que ma macro est utilisée ou non quelque part dans le fichier?

De plus, voir mon edit sur mon post précédent: j'ai aussi un warning lorsque ma macro est utilisée dans un autre fichier que celui où elle est définie. Typiquement, TOTO, TITI et TATA sont des macros définies dans mon .h.
TOTO est appelé dans mon .h et je n'ai aucun soucis (normal)
TITI n'est appeé ni dans le .h ni dans le .cpp, j'ai un warning (normal aussi)
Mais la macro TATA est appelée, non pas dans le .h mais dans mon .cpp et là, warning... Incompréhensible puisque la variable que je déclare est bien utilisée...
03/04/2013, 19h42
Bousk

Bonsoir,

rappelons que les macros ont pour seule résultat de remplacer leur appel par le code correspondant.
Si ta macro déclare une variable non utilisée, il y aura un warning pour cette variable.
- Soit tu fais pas appel à la macro
- Soit tu ajoutes un #if plus haut et un else pour déclarer une macro vide
->

Citation:

Qu'est ce qui pourrait controler le fait que je rentre ou non dans ce nouveau #ifndef?

Au hasard... toi ? Tu dois bien savoir pourquoi tu déclares ces macros et pourquoi elles ne sont pas utilisées. Les possibilités sont juste immenses et dépendantes uniquement du bon sens
>> numéro de version, define global, ...
- Soit tu te moques totalement de ce warning et le laisses faire sa vie
- Tu peux masquer le warning (c'est un simple pragma que Google te donnera en ~1s)
>> C'est je trouve un mauvais choix.
04/04/2013, 11h07
Josiane22

Citation:

Envoyé par Bousk

C'est je trouve un mauvais choix.

Là je suis totalement d'accord. C'est pour ça que je me creuse la tête à supprimer ce warning ;)

Citation:

Envoyé par Bousk

Bonsoir,

Tu dois bien savoir pourquoi tu déclares ces macros et pourquoi elles ne sont pas utilisées. Les possibilités sont juste immenses et dépendantes uniquement du bon sens
>> numéro de version, define global, ...

Oui et non... En fait, mes macros servent à trouver des maximums, calculer des racines, etc. sur des variables de types personnalisés.
(ca parait peut etre inutile de faire comme ça mais le code que j'ai à ma disposition à été validé ainsi et on me demande juste de supprimer les warning, pas de changer la manière de faire)

Le .h qui contient ces macros est lui appelé par plusieurs .cpp (une vingtaine je dirais). Dans chaque .cpp, on utilise telle ou telle macro, parfois aucune, parfois 2, etc. Du coup, à la compilation, en fonction du fichier .cpp considéré, j'ai plus ou moins de warning en fonction des macro vraiment utilisé.

Après, difficile de trouver une raison pour laquelle telle ou telle macro est utilisée. Ce serait comme faire une macro qui fait une addition et de demandé, "pourquoi tu fais une addition?"...
04/04/2013, 11h10
ternel

En conséquence, répartis chaque macro dans son propre .h, que tu inclueras en cas de besoin.
Comme cela risque d'être lourd en nombre de fichiers, fais un dossier dédié…
Chaque fichier contiendrais alors une seule variable, et les macros qui s'y rapportent

Bonjour,

Une solution est déclarer une fonction qui utilise la variable:
Code:

1 2 3 4 5 #ifndef TOTO static double truc; static inline double f_truc() { return truc; } #define TOTO(a) ((truc=(a)) == 0.0 ? 0.0 : 2*truc) //on est d'accord ca a pas trop d'interet mais ce n'est qu'un exmple #endif
Il n'y a pas d'avertissement pour un fonction non utilisée (en tout cas avec g++).

Quel compilateur utilises-tu ? Parce que avec g++, tu peux faire ça :
Code:

1 2 3 4 #ifndef TOTO static double __attribute__((__unused__)) truc; #define TOTO(a) ((truc=(a)) == 0.0 ? 0.0 : 2*truc) //on est d'accord ca a pas trop d'interet mais ce n'est qu'un exmple #endif
Sinon, si j'ai bien suivi, tu déclare une variable statique dans un en-tête, c'est intentionnel ? (Ça fait une variable différente dans chaque fichier *.cpp où tu inclus cet en-tête.)

04/04/2013, 17h11
ternel

C'est parce qu'elles sont statiques que je proposais un en-tête par variable.
Sinon, c'eut été une grave erreur de conception…
04/04/2013, 18h01
Josiane22

Bonjour à vous deux,

J'avais effectivement pensé à ta solution leternel mais ce qui me chagrine c'est de créer de devoir créer d'autres fichiers et d'ajouter un peu partout des includes. On s'éloigne un peu trop de mon code original.

Pour répondre à ta question nowahn, je pense que c'est voulu d'avoir des variables statiques. C'est un code que je viens de récupérer donc je ne peux pas etre plus catégorique...
Mais ta solution me plait assez si effectivement ca fonctionne (oui je compile avec g++).
Tu pourrais m'expliquer un peu ce que fais cette ligne? 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?

Si oui, quelle différence entre ça et une option de compilation qui ne m'afficherais pas les warning. J'ai un peu peur de cacher mon problème au lieu de le supprimer, non?
05/04/2013, 11h07
ternel
ton problème est d'avoir des déclarations non utilisées.

Tu as trois possibilités:
- dire "je sais" au compilateur plus ou moins subtilement (désactiver le warning, fausse fonction…)
- l'utiliser.
- supprimer la déclaration.
Ma solution est du troisième type, celle de nowahn du premier.
As-toi de voir ce que tu veux.
05/04/2013, 12h05
Josiane22

Etant une variable statique de chaque .cpp, j'osais espérer pouvoir déclarer mes variables uniquement lorsque la macro est utilisée.
Un peu comme si ma déclaration était dans le define de ma macro (Chose qui est impossible car une macro remplacant du code, la déclaration se trouverait au beau milieu du code)

Mais je crois que je vais devoir me rabattre sur une de vos solutions ;)

des macros qui fuient avec des trucs annexes, c'est pas propre.
Donc soit tu passe toto a ta macro soit si toto est un truc local, tu fais un block-macro
Code:

1 2 3 4 5 6 7 8 9 10 #define BIDULE() \ do \ { \ double toto = 0; \ ... \ } while(0) \ /**/ BIDULE();

09/04/2013, 11h26
Josiane22

Là ou ce que tu fais pose problème, c'est que ma macro à moi est appelé dans une ligne de calcul:

Genre:
Nombre= 1+ 2*TOTO(a)

Je ne peux donc pas déclarer ma variable dans la macro...

De plus, comment tu implanterais ta solution pour deux macros qui utilise la même variable. Si je le fais comme tu as dis, ca va fonctionner si l'une ou l'autre des macros est utilisée. Mais si les deux le sont, je vais avoir deux fois la déclaration...

Même problème si la macro est appelée deux fois de suites...
09/04/2013, 13h57
ternel

Alors ne fais pas des macros, mais des factories/singletons.
Tu es en C++, profites-en.

Une classe pour chaque variable. Un cpp pour instancier les singletons, et roule.
09/04/2013, 14h24
Josiane22

En fait, je travaille sur un code que j'ai récupéré, et qui, si j'ai bien compris, à été programmer il y à 10 ans par des gens qui ne maitrisait pas du tout le C++. J'ai donc des manières de faire qui sont étranges, des bouts de codes qui semblent peu optimisés.

Aujourd'hui, il tourne sur du Redhat 4 et je dois le faire tourner sur du Redhat 5. En plus de résoudre les erreurs à la compile pour que ca fonctionne, j'en profite pour supprimer les warnings (qui polluent vraiment la lisibilité de ce qui se fait à la compilation). En gros, j'ai à peu près 4500 lignes de warnings sur les 5000 lignes qui sont sorties à la compilation.

Mon problème, c'est que je ne peux pas changer le code en profondeur. Pour des soucis de validation, je ne dois pas trop toucher ce qui à été fait. Par exemple, le code est mal fichu avec ces macros mais c'est pas mon soucis (c'est complètement débile, soit, mais c'est comme ça...)
Donc je dois faire avec et supprimer ces warnings de la façon la plus propre possible sans pour autant remplacer des pans entier de code. Les macros sont là, à moi de virer le warning avec le moins de changement possible.
Ce que proposait Nowahn allait dans ce sens. Y'avait juste à rajouter une ou deux choses dans la déclaration et c'était bon. Certes c'est pas le plus propre mais ca va dans le sens de ce qui m'est demandé. J'aurais bien aimé utilisé la solution de Joel qui allait aussi dans ce sens mais ça ne peut fonctionner avec mon code...
09/04/2013, 20h38
Bousk

Citation:

Envoyé par Josiane22

Genre:
Nombre= 1+ 2*TOTO(a)

Là ta variable est utilisée, donc y'a pas lieu d'avoir de warning qui indique sa non-utilisation..

Citation:

Envoyé par Josiane22

Les macros sont là, à moi de virer le warning avec le moins de changement possible.
Ce que proposait Nowahn allait dans ce sens. Y'avait juste à rajouter une ou deux choses dans la déclaration et c'était bon. Certes c'est pas le plus propre mais ca va dans le sens de ce qui m'est demandé. J'aurais bien aimé utilisé la solution de Joel qui allait aussi dans ce sens mais ça ne peut fonctionner avec mon code...

Tu peux aussi virer des error, ça n'en fait pas pour autant une bonne solution.
La meilleure solution c'est de les laisser, ils sont pas là par hasard, et faire un cache-misère pour les camoufler est la meilleure idée pour se retrouver avec des bugs "dont on ne sait pas du tout d'où ça vient parce qu'il n'y a aucune indication d'erreur/warning".
Btw, si le code a 10 ans et les variables sont toujours inutilisées...
11/04/2013, 22h12
moldavi

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.
12/04/2013, 14h57
nowahn
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).
14/04/2013, 19h52
Bousk

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.