11
votes

Supprimer l'avertissement de variable non utilisé en C ++ => Bug de compilateur ou bug de code?

Actuellement, j'utilise le modèle de fonction suivant pour supprimer les avertissements variables inutilisés: xxx pré>

Cependant, lorsque vous portez à Cygwin de Linux, je reçois maintenant des erreurs de compilateur sur g ++ 3.4.4 ( Sur Linux je suis 3.4.6, alors peut-être que ceci est une solution de bogue?): P> xxx pré>

L'argument à inutilisé est une variable de membre déclarée comme: p>

template<typename T>
void unused(T const &) { }

int main() {
  volatile bool x = false;
  unused(!x); // type of "!x" is bool
}


2 commentaires

Je ne peux pas reproduire le problème. Pouvez-vous poster du code qui reproduit le problème.


Williamkf - Pourquoi avez-vous accepté une réponse que vous indiquez clairement ne résout pas votre problème?


5 Réponses :


2
votes

Dans GCC, vous pouvez définir une macro comme suit:

#ifdef UNUSED
#elif defined(__GNUC__)
# define UNUSED(x) UNUSED_ ## x __attribute__((unused))
#elif defined(__LCLINT__)
# define UNUSED(x) /*@unused@*/ x
#else
# define UNUSED(x) x
#endif 


2 commentaires

Oui, mais c'est dépendant du compilateur. La question donne le moyen courant de le faire sous une manière dépendante non compileuse, comme indiqué, il exerce un bogue dans le compilateur.


+1 C'est la réponse la plus portable. En outre, GCC prend en charge #pragma inutilisé - voir aussi la documentation de la directive _pragma .



9
votes

Je ne suis pas sûr que cela soit portable, mais c'est l'idiome que j'ai habituellement utilisé pour supprimer des avertissements sur les variables inutilisées. Le contexte ici est un gestionnaire de signal qui n'est utilisé que pour attraper sigint code> et sigterm code>, donc si la fonction est appelée, je sais qu'il est temps de quitter le programme.

volatile bool app_killed = false;
int signal_handler(int signum)
{
    (void)signum; // this suppresses the warnings
    app_killed = true;
}


4 commentaires

Oui, c'est à la fois légal C ++ et portable.


Si vous souhaitez effectuer cette approche compatible avec le code existant qui utilise inutilisé (), définissez une macro: #define inutilisé (x) ((vide) x)


Cela ne fonctionnera pas si la variable est une référence à un type incomplet. Par exemple, struct A; void f (a & a_) {(vide) a_; } donnera une erreur de compilation.


Si vous n'aviez pas besoin d'utiliser sur Signum, que si vous venez de le faire un paramètre sans nom ... comme ceci: int Signal_Handler (int) Il convient au même prototype et éventuellement sauver quelques Mémoire



28
votes

La manière réelle d'indiquer que vous n'utilisez pas réellement un paramètre ne lui donne pas un nom:

int f(int a, float) {
     return a*2;
}


7 commentaires

Oui, et j'utilise normalement quelque chose comme INT F (int comptage, flotteur / * epsilon * /) afin de nommer le paramètre non utilisé et sa signification.


En effet ur, c'est de bonnes manières, j'ai oublié ça, mais vous avez absolument raison.


+1. Avec la suggestion de votre urine, la manière la plus propre et la plus expressive de le faire.


Ce n'est pas ce que la question pose la question. Omettre le nom de la variable pour la fonction argore fonctionne bien, mais la variable est déclarée à l'intérieur de la fonction et ne peut donc pas être omise. En outre, dans ce cas, le nom de la variable est nécessaire car il est utilisé dans certains cas #Ifdef et que l'inutilisé est pour l'autre afin qu'aucun avertissement ne soit généré.


Si vous ne l'utilisez pas, ne déclarez-le pas. Même plus simple!


Le problème de ne pas nommer les paramètres est que vous pourriez avoir besoin de les inspecter plus tard. Lorsque vous essayez de voir leurs valeurs dans le débogueur, vous souhaiterez que vous leuriez des noms.


S'ils sont inutilisés, il n'y a pas grand chose à inspecter dans le débogueur.



4
votes

C'est un bug de compilateur et il n'y a pas de contournement connu:

http://gcc.gnu.org/bugzilla/show_bug.cgi ? id = 42655

Il est fixé en v4.4.


0 commentaires

2
votes

La réponse proposée par Haavee (modifiée par UR) est celle que je voudrais utiliser normalement: xxx

Le vrai problème se produit lorsque l'argument est parfois mais pas Toujours utilisé dans la méthode, par exemple: xxx

maintenant, je ne peux pas commenter le nom de paramètre epsilon car cela brisera ma construction de journalisation (je ne veux pas insérer Un autre #Ifdef dans la liste des arguments parce que cela rend le code beaucoup plus difficile à lire).

Donc, je pense que la meilleure solution serait d'utiliser la suggestion de Tom: xxx

Mon seul inquiétude serait que certains compilateurs puissent avertir le «vide) Epsilon;" Déclaration, par exemple "L'affirmation n'a aucun effet" AVERTISSEMENT ou d'une part, je suppose que je vais deviner que je vais devoir tester sur tous les compilateurs que je suis susceptible d'utiliser ...


0 commentaires