Question

À l'heure actuelle, je suis en utilisant le modèle de fonction suivante pour supprimer les avertissements variables non utilisés:

template<typename T>
void
unused(T const &) {
  /* Do nothing. */
}

Cependant, lors du portage à cygwin de Linux, je reçois maintenant des erreurs du compilateur sur g ++ 3.4.4 (Sur linux je suis 3.4.6, alors peut-être c'est un bug fix?):

Write.cpp: In member function `void* Write::initReadWrite()':
Write.cpp:516: error: invalid initialization of reference of type 'const volatile bool&' from expression of type 'volatile bool'
../../src/common/Assert.h:27: error: in passing argument 1 of `void unused(const T&) [with T = volatile bool]'
make[1]: *** [ARCH.cygwin/release/Write.o] Error 1

L'argument utilisé est une variable membre déclaré comme suit:

  volatile bool readWriteActivated;

Est-ce un bug du compilateur ou un bug dans mon code?

Voici le cas de test minimal:

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

int main() {
  volatile bool x = false;
  unused(!x); // type of "!x" is bool
}
Était-ce utile?

La solution 3

Il est un bug du compilateur et il n'y a pas de travail connus contournements:

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

Il est fixé dans v4.4.

Autres conseils

La façon réelle d'indiquer que vous n'utilisez pas réellement un paramètre ne donne pas un nom:

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

compilera partout avec tous les avertissements sous tension, sans avertissement au sujet du flotteur utilisé. Même si l'argument a un nom dans le prototype (par exemple int f(int a, float f);), il ne peut toujours pas se plaindre.

Je ne suis pas 100% sûr que ce soit portable, mais c'est l'idiome que je l'ai habituellement utilisé pour supprimer des avertissements sur les variables inutilisées. Le contexte ici est un gestionnaire de signal qui est utilisé uniquement pour attraper SIGINT et SIGTERM, donc si la fonction est toujours appelé, je sais qu'il est temps pour le programme pour quitter.

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

J'ai tendance à ne pas aimer qui encombrent la liste des paramètres avec __attribute__((unused)), puisque l'affaire coulé à vide fonctionne sans avoir recours à des macros pour Visual C ++.

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 

Les paramètres marqués par cette macro supprime le GCC émet d'avertissement non utilisés (et renomme le paramètre avec un préfixe de UNUSED_). Pour Visual Studio, vous pouvez supprimer les avertissements avec une directive #pragma.

La réponse proposée par haavee (modifié par ur) est celui que je normalement utiliser:

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

Le vrai problème se produit lorsque l'argument est parfois mais pas toujours utilisé dans le procédé, par exemple:.

int f(int a, float epsilon) {
#ifdef LOGGING_ENABLED
     LOG("f: a = %d, epsilon = %f\n", a, epsilon);
#endif
     return a*2;
}

Maintenant, je ne peux pas commenter le nom du paramètre epsilon parce que cela va me casser la construction de l'exploitation forestière (je ne veux pas insérer une autre #ifdef dans la liste des arguments parce que rend le code beaucoup plus difficile à lire).

Je pense donc que la meilleure solution serait d'utiliser la suggestion de Tom:

int f(int a, float epsilon) {
(void) epsilon;    // suppress compiler warning for possibly unused arg
#ifdef LOGGING_ENABLED
     LOG("f: a = %d, epsilon = %f\n", a, epsilon);
#endif
     return a*2;
}

Mon seul souci serait que certains compilateurs pourraient mettre en garde contre la « (vide) epsilon; » déclaration, par exemple avertissement « déclaration n'a pas d'effet » ou quelque chose comme - je suppose que je vais devoir tester sur tous les compilateurs je suis susceptible d'utiliser ...

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top