Est l'aide de #pragma warning push/pop de la bonne façon de modifier temporairement le niveau d'avertissement?

De temps en temps c'est difficile d'écrire du code C++ qui ne serait pas émettre des avertissements à tous. Avoir des avertissements activé est cependant une bonne idée. Donc, il est souvent nécessaire de désactiver les avertissements autour de certains aspects spécifiques de la construction et leur permet dans tous les autres morceaux de code.

J'ai vu deux manières de le faire jusqu'à présent.

La première est d'utiliser #pragma warning( push ) et #pragma warning( pop ):

 #pragma warning( push )
 #pragma warning( disable: ThatWarning )
 //code with ThatWarning here
 #pragma warning( pop )

La seconde est d'utiliser #pragma warning( default ):

 #pragma warning( disable: ThatWarning )
 //code with ThatWarning here
 #pragma warning( default: ThatWarning )

Le problème que je vois dans la seconde variante est qu'elle ignore l'origine de niveau d'avertissement - l'avertissement peut avoir été éteint avant que, ou de son niveau d'avertissement peut avoir été modifié. À l'aide de default serait jeter ces modifications.

La première approche a l'air propre. Existe-il des problèmes avec elle? Sont-il de meilleures façons d'atteindre le même?

  • La portabilité, mais comme ce n'est taggés avec visual c++, ce n'est probablement pas un problème pour vous. Malheureusement, il ne semble pas la solution qui tombe n'importe où près de "ascetically plaire". Je vais toujours avec le push/pop méthode.
InformationsquelleAutor sharptooth | 2010-11-16
  1. 37

    La première méthode est la meilleure façon de le faire, de l'OMI. Je ne connais pas de problèmes avec elle.

    Simplement garder à l'esprit qu'un #pragma est compilateur spécifique, donc ne vous attendez pas à travailler sur chaque compilateur là-bas 🙂

    • Je suis venu avec un possible problème gênant pour la première approche. Si le \\code with ThatWarning here a un (3e partie) de la tête, et que la tête a un #pragma warning( disable: AnotherWarning) puis le menu désactive le désactiver. Alors on peut dire que c'est une bonne chose, la bibliothèque concepteur peut être faire quelque chose dans un modèle qui génère un avertissement, qu'ils ont déterminées est sûr. Maintenant, toute utilisation de ce modèle dans votre code va générer cet avertissement, mais il sera marqué comme la bibliothèque. Il n'est pas clair du tout ce que la ligne de votre code est le déclenchement d'une alarme dans la bibliothèque.
    • Fin de la réponse-o-rama .... mais ... que le même problème se produit avec l'autre méthode de trop ...
    • Comme indiqué ici correctement, la première méthode est la meilleure et il n'y a rien de mal à cela. Ce point clairement indiqué dans "C++ normes de Codage 101 Règles, des lignes Directrices et des Meilleures Pratiques", par Herb Sutter et Andrei Alexandrescu,1ère Édition, 2005 (page 19).
    InformationsquelleAutor Goz
  2. 41

    Cela va fonctionner avec plusieurs compilateurs (et les différentes versions de compilateurs).

    En-tête de "pousser"

    #if defined(__clang__)
# pragma clang diagnostic push
#endif

#if defined(_MSC_VER)
# pragma warning(push)
#endif

#if defined(YOUR_FAVORITE_COMPILER)
# pragma your compiler push warning
#endif

    En-tête "pop"

    #if defined(__clang__)
# pragma clang diagnostic pop
#endif

#if defined(_MSC_VER)
# pragma warning(pop)
#endif

    Un avertissement

    #if defined(__clang__)
# pragma clang diagnostic ignored "-Wunused-parameter"
# pragma clang diagnostic ignored "-Wunused-variable"
#  if __has_warning("-Wnew-special-warning")
#   pragma clang diagnostic ignored "-Wnew-special-warning"
#  endif
#endif

#if defined(_MSC_VER)
# pragma warning(disable: 4100) //unreferenced formal parameter
# if _MSC_VER > _MSC_SOME_VERSION
#  pragma warning(disable: xxxx) //disable one more for special version
# endif
#endif

    D'utilisation

    //This code reports warnings
//...
#include <ignore_compiler_warning/push>
#include <ignore_compiler_warning/warning_type_1>
#include <ignore_compiler_warning/warning_type_2>
#include <ignore_compiler_warning/warning_type_3>
//This code ignores warnings type_{1,2,3}
//...
#include <ignore_compiler_warning/pop>
//Back to reporting warnings
//...

    en Outre comprendre des gardes pouvez vérifier qu'il n'y a pas de double push/pop/désactiver l'avertissement de pragmas.

    Mise à jour

    InformationsquelleAutor
  3. 37

    Trop tard pour acéré, mais pour tous les googlers là:

    #pragma warning ( suppress: ThatWarning )
//one single line with ThatWarning

    est l'abréviation de (généralement depuis VS 2008, mais dans VS 2005 pour Analyseur de Code avertissements uniquement):

    #pragma warning ( push )
#pragma warning ( disable: ThatWarning )
//one single line with ThatWarning
#pragma warning ( pop )
    • Merci beaucoup! suppress est certainement le droit de réponse ici, et bien plus élégante que push/disable/pop ou disable/enable.
    • était la seule façon de travailler dans vs2012 , pousser désactiver etc ..n'ont pas de travail
    • Je suppose que c'est la méthode que la plupart des codeurs souhaitez.
    • Un autre mot pour le sage; perdre le préfixe C; utilisez simplement le nombre. Sinon, la directive #pragma génère encore plus de mises en garde et ne fait rien.
    • Bien que c'est le plus élégant de la méthode (si on peut dire une telle chose), il ne fonctionne pas toujours comme prévu. Comme toujours, le diable est dans le détail: #pragma warning (suppress) ne fonctionne que sur les ligne: de code, pas les bloc. Je soulève cette question depuis TS a déclaré "code d'avertissement".
    InformationsquelleAutor m3tikn0b
  4. 13

    L'approche correcte (bien qu'un peu moche)

    #ifdef _MSC_VER
 #pragma warning( push )
 #pragma warning( once: ThatWarning )
#endif
 //code with ThatWarning here
#ifdef _MSC_VER
 #pragma warning( pop )
#endif
    • TS veut désactiver temporairement un avertissement pour une partie de code. #pragma warning(une fois) ne fonctionnera pas, car elle permet tout de même l'affichage de l'avertissement (juste une fois). Je me demande si le upvoters effectivement testé la solution. (Je l'ai fait, ça n'a pas fonctionné).
    • 'une fois' vs 'désactiver'. Je crois que nos humbles lecteurs vont comprendre. Un débordement de pile lecteurs sont clairement parmi les meilleurs de l'humanité a à offrir. Ou quelque chose.
    InformationsquelleAutor ronag
  5. 3

    Vous pouvez désactiver les avertissements spécifiques dans le projet ou d'un fichier et options de ce paramètre s'applique comme "par défaut" par ces #pragmas à la portée pertinente. Quelques-uns des avertissements dans VS2005 sont tellement inutiles/ennuyeux que cela nettoie la sortie tout à fait un peu, si vous utilisez /W4.

    C'est dans les Propriétés de sous Propriétés de Configuration -> C/C++ -> Avancé.

    InformationsquelleAutor Steve Townsend
  6. 2

    Je n'ai pas de problèmes avec la première variante. Peut-être la meilleure façon est d'utiliser les éléments suivants:

     #pragma warning( push )
 #pragma warning( once: ThatWarning )
 //code with ThatWarning here
 #pragma warning( pop )

    Cela vous permettra de savoir qu'il y a encore des avertissements dans le code, mais les messages d'avertissement ne sera pas si ennuyeux. Mais c'est question de goût.

    • Cet avertissement: msdn.microsoft.com/en-us/library/1ywe7hcy(SV.80).aspx est le saignement ennuyeux, même si vous ne le voyez qu'une fois 😉
    • Le problème ici est qu'il peut être utile de faire du compilateur "traiter les avertissements comme des erreurs". Pour les erreurs qui ne peuvent pas être fixe (c'est à dire quelques la 3e partie de la dépendance), alors vous devez désactiver en toute sécurité.
    InformationsquelleAutor Kirill V. Lyadvinsky