Discussion :

[Josiane22]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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...

Auriez-vous donc une astuce? (je ne veux pas par contre d'options de compil' qui cacheraient le warning. Je veux le supprimer.)

[ternel]

il suffit de l'utiliser.
au moins une fois.
Pour ce faire, dans le main, tu peux ajouter (void)truc;

[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...

[ternel]

tu ne les utilises pas, ne les d�fini pas.
ca doit �tre possible, quitte � placer les defines dans un fichier autonome

[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...

[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.

[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...

[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
->

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.

[Josiane22]

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

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?"...

[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

[nowahn]

Bonjour,

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

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

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 C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

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.)

[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�

[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?

[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.

[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

[Joel F]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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

[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...

[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.

[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...

[Bousk]

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..

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...