Meilleur niveau d’avertissement du compilateur pour les compilateurs C / C ++?

Ceci est un ensemble de drapeaux extra-paranoïaques que j’utilise pour le code C ++:

-g -O -Wall -Weffc++ -pedantic \ -pedantic-errors -Wextra -Waggregate-return -Wcast-align \ -Wcast-qual -Wchar-subscripts -Wcomment -Wconversion \ -Wdisabled-optimization \ -Werror -Wfloat-equal -Wformat -Wformat=2 \ -Wformat-nonliteral -Wformat-security \ -Wformat-y2k \ -Wimplicit -Wimport -Winit-self -Winline \ -Winvalid-pch \ -Wunsafe-loop-optimizations -Wlong-long -Wmissing-braces \ -Wmissing-field-initializers -Wmissing-format-atsortingbute \ -Wmissing-include-dirs -Wmissing-noreturn \ -Wpacked -Wpadded -Wparentheses -Wpointer-arith \ -Wredundant-decls -Wreturn-type \ -Wsequence-point -Wshadow -Wsign-compare -Wstack-protector \ -Wssortingct-aliasing -Wssortingct-aliasing=2 -Wswitch -Wswitch-default \ -Wswitch-enum -Wsortinggraphs -Wuninitialized \ -Wunknown-pragmas -Wunreachable-code -Wunused \ -Wunused-function -Wunused-label -Wunused-parameter \ -Wunused-value -Wunused-variable -Wvariadic-macros \ -Wvolatile-register-var -Wwrite-ssortingngs 

Cela devrait vous donner quelque chose pour commencer. Selon le projet, vous devrez peut-être le réduire afin de ne pas voir les alertes provenant de bibliothèques tierces (qui sont généralement assez imprudentes quant à l’absence d’avertissement). Par exemple, le code vectoriel / masortingciel Boost générera beaucoup d’émissions de bruit.

Une meilleure façon de gérer de tels cas est d’écrire un wrapper autour de g ++ qui utilise toujours des avertissements réglés jusqu’à max mais permet de les supprimer pour qu’ils soient visibles pour des fichiers / numéros de ligne spécifiques. J’ai écrit un tel outil il y a longtemps et je le publierai une fois que j’aurai le temps de le nettoyer.

Sur Visual C ++, j’utilise /W4 et /WX (traite les avertissements comme des erreurs).

VC a également /Wall , mais il est incompatible avec les en-têtes standard.

Je choisis de traiter les avertissements comme des erreurs, car cela me force à les corriger. Je répare tous les avertissements, même si cela implique d’append #pragma pour ignorer l’avertissement – de cette façon, je déclare explicitement que je suis au courant de l’avertissement (pour que les autres développeurs ne m’en envoient pas par courrier électronique).

Je crois que VC soutient également

 #pragma message ("note to self") 

Mais au fur et à mesure que le système grandit et que vous construisez 30 développeurs travaillant en même temps, il faut des jours pour lire toutes les notes, même dans ce cas-là, rien ne va plus que de lire casser sous le stress ne pas pouvoir suivre et devoir démissionner …

Non vraiment, la quantité d’avertissements va rapidement augmenter si vous les autorisez, et vous ne pourrez pas repérer les plus importants (variables non initialisées, ce pointeur utilisé dans constructeur, …).

C’est pourquoi j’essaie de traiter les avertissements comme des erreurs: la plupart du temps, le compilateur a raison de m’avertir, et s’il ne le fait pas, je le documente dans le code et ajoute

 #pragma warning ( push ) #pragma warning ( 4191 : disable ) // violent code, properly documented #pragma warning ( pop ) 

Je viens de lire qu’ils ont aussi un warning ( N : suppress ) pragma.

J’ai tendance à utiliser -Wall (parce que tout le monde fait des bogues, personne n’est parfait), mais je n’utilise pas -Werror (traiter les avertissements comme des erreurs) parce que de temps en temps gcc avertit de toutes les manières (faux positifs).

Je suis d’accord avec Litb pour toujours utiliser -Wall. De plus, si vous voulez vous assurer que votre code est conforme, vous pouvez également utiliser -pedantic. Un autre avertissement qui peut être utile si vous manipulez des unions et des structures au niveau de l’octet est -Wpadded.

Je fais tout le développement avec Warning as Errors activé.

Comme je continue à développer en VC6, j’ai beaucoup de # pragma dans mon code (4786 principalement).

Il y a une belle liste d’options pour GCC ici: http://mces.blogspot.com/2008/12/year-end-cleaning-ie-on-warning-options.htm . -Wall n’active pas tous les avertissements possibles et certains doivent être explicitement activés.

J’aime les prototypes muraux et ssortingcts, ainsi que les définitions de fonctions implicites. Les erreurs sur ceux-ci peuvent être très utiles. Il y a aussi -Wextra qui va ramasser toutes sortes de choses comme des choses que vous avez l’intention d’être conditionnelles mais écrites accidentellement comme des déclarations:

 if (something); classic_way_to_leak_memory(); 

Sur les systèmes de type Unix, vous devez respecter les préférences ENV de l’utilisateur. Ce qu’ils voient et rapportent peut donc être complètement différent de ce dont vous avez besoin 🙂

Je suis aussi un démon de type punning, donc j’ai tendance à définir -Fnom-ssortingct-aliasing, à moins que l’utilisateur ne le veuille. La gestion de la mémoire sécurisée dans C classique est difficile à accomplir autrement.

Sur GCC, de préférence, -Wall -Wextra -Wwrite-ssortingngs -Werror et spécifie également un standard avec std= . Quelle norme dépend du projet: principalement sur son portabilité.

La raison pour laquelle j’utilise -Werror est que les avertissements sont inacceptables (pour moi) même s’ils ne représentent pas un vrai bogue. Je préfère contourner ce qui a causé l’avertissement, plutôt que de devoir ignorer les avertissements chaque fois que je comstack pour le rest de ma vie. Une fois que vous autorisez les avertissements dans la compilation, il est trop facile d’en manquer un qui n’était pas là la dernière fois.

Bien sûr, lorsque vous traitez avec du code tiers, vous ne pouvez parfois pas vous débarrasser des avertissements. Ensuite, je déciderais au cas par cas si je devrais assouplir les options -W , supprimer -Werror et écrire un script pour vérifier que seuls les avertissements se produisent ou peut-être modifier le code tiers (soit pour “réparer”). l’avertissement ou de le désactiver avec des pragmas si possible).

Dans Visual CI, utilisez / w3. Je trouve que w4 génère trop de bruit (beaucoup des bibliothèques MS) pour passer à travers chaque build. Les avertissements supplémentaires sont très mineurs et n’ont pas encore causé de bogue.

personne n’a encore mentionné le compilateur Intel:

https://software.intel.com/sites/products/documentation/doclib/iss/2013/comstackr/cpp-lin/GUID-D060680A-1A18-4574-8291-5C74E6E31335.htm

-w3 est assez bavard, alors je suggère -w2

J’aime aussi vérifier tous les avertissements possibles qui donnent le compilateur dans mon projet. Malheureusement, la réponse à propos du compilateur Intel C ++ n’était pas très informative pour moi (link is dead). J’ai fait mes propres recherches.

Parce que j’utilise Qt 5 et qmake, j’ai un niveau d’avertissement prédéfini -w1 . Je ne peux rien faire avec ça. Mais ce n’est pas tout et ICC a plus de clés:

 -Wcomment -Weffc++ -Wextra-tokens -Wformat -Winline // don't use, show only for example -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnon-virtual-dtor -Wp64 -Wpointer-arith -Wremarks -Wreturn-type -Wsign-compare -Wssortingct-aliasing -Wssortingct-prototypes -Wsortinggraphs -Wuninitialized -Wunknown-pragmas -Wunused-variable 

En savoir plus sur toutes les clés .

Je veux aussi append que, contrairement à GCC, ICC produit plusieurs avertissements pour une clé, par exemple la clé -Weffc ++ . Si vous ne souhaitez voir que plusieurs avertissements de toutes les listes, utilisez la touche -wd .

Je désactive: -wd1418,2012,2015,2017,2022,2013 . Et les avertissements -wd1572,873,2259,2261 ont été désactivés par défaut dans qmake.

J’utilise PCH et j’ai trouvé très ennuyeux de voir dans Qt Creator des messages sur l’utilisation du fichier PCH comme une erreur. Pour désactiver, utilisez -Wno-pch-messages .

Pour désactiver l’avertissement dans le code, j’utilise:

 #if defined(Q_CC_INTEL) #pragma warning( push ) #pragma warning( disable: 2021 ) #endif // some code #if defined(Q_CC_INTEL) #pragma warning( pop ) #endif 

Merci à tous pour leurs réponses. Cela fait longtemps que je n’ai rien utilisé d’autre que gcc / g ++. Ceux que j’ai dû utiliser il y a longtemps sont

 -fmessage-length = 0 (puisque g ++ avait la mauvaise habitude des messages de rupture de ligne)

 -Wno-désapprouvé (depuis que j'ai travaillé sur une base de code préexistant à l'espace de noms std)

Je me souviens que (il y a au moins 5 ans) tout ce qui était supérieur au niveau d’avertissement par défaut du compilateur Sun Workshop CC était trop élevé. Je pense aussi que cela a pu être vrai pour le compilateur Intel. Je n’ai pas été à jour avec les compilateurs non gnu depuis un moment.

Les compilateurs GCC deviennent plus ssortingcts avec chaque nouvelle version. Utilisez le drapeau -ansi pour générer des avertissements en cas de violation de l’interprétation la plus ssortingcte des normes linguistiques ANSI. C’est généralement ce qui arrive à fonctionner dans votre compilateur actuel, mais peut générer des erreurs dans la prochaine version ou dans d’autres compilateurs. Cet indicateur vous aidera à ne pas avoir à porter votre code à chaque fois que vous changez de compilateur / version.