Pourquoi devrais-je toujours activer les avertissements du compilateur?
J'entends souvent que lors de la compilation de programmes C et C++, je devrais "toujours activer les avertissements du compilateur". Pourquoi est-ce nécessaire? Comment je fais ça?
Parfois, j'entends aussi que je dois "traiter les avertissements comme des erreurs". Devrais-je? Comment je fais ça?
Pourquoi activer les avertissements?
Les compilateurs C et C++ sont notoirement mauvais pour signaler certaines erreurs de programmation courantes par défaut, telles que:
- oublier d'initialiser une variable
- oublier à
returnune valeur d'une fonction - les arguments des familles
printfetscanfne correspondent pas à la chaîne de format - une fonction est utilisée sans être déclarée au préalable (C uniquement)
Ceux-ci peuvent être détectés et signalés, mais généralement pas par défaut; cette fonctionnalité doit être explicitement demandée via les options du compilateur.
Comment activer les avertissements?
Cela dépend de votre compilateur.
Les compilateurs Microsoft C et C++ comprennent les commutateurs comme /W1, /W2, /W3, /W4 et /Wall. Utilise au moins /W3. /W4 et /Wall peut émettre de faux avertissements pour les fichiers d'en-tête du système, mais si votre projet se compile proprement avec l'une de ces options, allez-y. Ces options s'excluent mutuellement.
La plupart des autres compilateurs comprennent des options telles que -Wall, -Wpedantic et -Wextra. -Wall est indispensable et tout le reste est recommandé (notez que, malgré son nom, -Wall active uniquement les avertissements les plus importants, pas tous d'entre eux). Ces options peuvent être utilisées séparément ou toutes ensemble.
Votre IDE peut avoir un moyen de les activer à partir de l'interface utilisateur.
Pourquoi traiter les avertissements comme des erreurs? Ce ne sont que des avertissements!
Un avertissement du compilateur signale un problème potentiellement grave dans votre code. Les problèmes énumérés ci-dessus sont presque toujours fatals; d'autres peuvent l'être ou non, mais vous voulez que la compilation échoue même si cela se révèle être une fausse alarme. Analysez chaque avertissement, trouvez la cause première et corrigez-le. Dans le cas d'une fausse alarme, contournez-la, c'est-à-dire utilisez une fonction ou une construction de langage différente pour que l'avertissement ne soit plus déclenché. Si cela s'avère très difficile, désactivez cet avertissement particulier au cas par cas.
Vous ne voulez pas simplement laisser des avertissements comme avertissements, même s'ils sont tous de fausses alarmes. Cela pourrait être OK pour de très petits projets où le nombre total d'avertissements émis est inférieur à 7. Rien de plus, et il est facile pour un nouvel avertissement de se perdre dans un flot d'anciens familiers. Ne permettez pas ça. Faites simplement compiler proprement tout votre projet.
Notez que cela s'applique au développement du programme. Si vous publiez votre projet dans le monde sous la forme source, il peut être judicieux de ne pas fournir -Werror ou équivalent dans votre publié script de build. Les gens peuvent essayer de créer votre projet avec une version différente du compilateur, ou avec un compilateur tout à fait différent, qui peut avoir un ensemble d'avertissements différent activé. Vous voudrez peut-être que leur version réussisse. C'est toujours une bonne idée de garder les avertissements activés, afin que les personnes qui voient des messages d'avertissement puissent vous envoyer des rapports de bogues ou des correctifs.
Comment traiter les avertissements comme des erreurs?
Cela se fait à nouveau avec les commutateurs du compilateur. /WX est pour Microsoft, la plupart des autres utilisent -Werror. Dans les deux cas, la compilation échouera si des avertissements sont générés.
C est, comme on le sait, un langage de bas niveau comme les HLL. C++, bien qu'il puisse sembler être un langage de niveau considérablement plus élevé que C, partage toujours un certain nombre de ses traits. Et l'un de ces traits est que les langages ont été conçus par des programmeurs, pour des programmeurs - et, spécifiquement, des programmeurs qui savaient ce qu'ils faisaient.
[Pour le reste de cette réponse, je vais me concentrer sur C. La plupart de ce que je vais dire s'applique également au C++, mais peut-être pas aussi fortement. Bien que Bjarne Stroustrup l'ait dit de façon célèbre, "C facilite la prise de vue dans le pied; C++ rend la tâche plus difficile, mais quand vous le faites, vous vous enlevez toute la jambe." ]
Si vous savez ce que vous faites - vraiment savez ce que vous faites - parfois vous devrez peut-être "enfreindre les règles". Mais la plupart du temps, la plupart d'entre nous seront d'accord pour dire que des règles bien intentionnées nous empêchent tous d'avoir des ennuis, et que d'enfreindre ces règles sans le vouloir est une mauvaise idée.
Mais en C et C++, il y a un nombre étonnamment élevé de choses que vous pouvez faire qui sont de "mauvaises idées" mais qui ne sont pas formellement "contraires aux règles". Parfois, c'est une mauvaise idée parfois (mais peut être défendable d'autres fois); Parfois, c'est une mauvaise idée presque tout le temps. Mais la tradition a toujours été de ne pas avertir de ces choses - car, encore une fois, l'hypothèse est que les programmeurs savent ce qu'ils font, ils ne le feraient pas t faire ces choses sans une bonne raison, ils seraient ennuyés par un tas d'avertissements inutiles.
Mais bien sûr, tous les programmeurs ne savent pas vraiment ce qu'ils font. Et, en particulier, chaque programmeur C (peu importe son expérience) passe par une phase d'être un programmeur C débutant. Et même les programmeurs C expérimentés peuvent être négligents et faire des erreurs.
Enfin, l'expérience a montré non seulement que les programmeurs font des erreurs, mais que ces erreurs peuvent avoir des conséquences réelles et graves. Si vous faites une erreur et que le compilateur ne vous en avertit pas et que le programme ne se bloque pas immédiatement ou ne fait pas quelque chose de mal à cause de cela, l'erreur peut se cacher là, cachée, parfois pendant des années, jusqu'à ce qu'elle provoque un vraiment gros problème.
Il s'avère donc que, la plupart du temps, les avertissements sont une bonne idée, après tout. Même les programmeurs expérimentés ont appris (en fait, c'est " en particulier les programmeurs expérimentés ont appris") que, dans l'ensemble, les avertissements ont tendance à faire plus de bien que nuire. Pour chaque fois que vous avez fait quelque chose de mal délibérément et que l'avertissement était une nuisance, il y a probablement au moins dix fois que vous avez fait quelque chose de mal par accident et l'avertissement vous a évité d'autres ennuis. Et la plupart des avertissements peuvent être désactivés ou contournés ces quelques fois où vous voulez vraiment faire la "mauvaise" chose.
(Un exemple classique d'une telle "erreur" est le test if(a = b). La plupart du temps, c'est une erreur, donc la plupart des compilateurs de nos jours en avertissent - certains même par défaut. Mais si vous vraiment voulait à la fois affecter b à a et tester le résultat, vous pouvez désactiver l'avertissement en tapant if((a = b)).)
La deuxième question est: pourquoi voudriez-vous demander au compilateur de traiter les avertissements comme des erreurs? Je dirais que c'est à cause de la nature humaine, en particulier, la réaction trop facile de dire "Oh, c'est juste un avertissement, ce n'est pas si important, je vais nettoyer ça plus tard." Mais si vous êtes un procrastinateur (et je ne sais pas pour vous, mais je suis un terrible procrastinateur), il est facile de repousser nécessairement nettoyer pour toujours - et si vous avez l'habitude d'ignorer les avertissements, il devient de plus en plus facile de manquer un message d'avertissement important qui est là, inaperçu, au milieu de tous ceux que vous ignorez.
Donc, demander au compilateur de traiter les avertissements comme des erreurs est une petite astuce que vous pouvez jouer sur vous-même pour contourner cette cible humaine.
Personnellement, je n'insiste pas autant pour traiter les avertissements que les erreurs. (En fait, si je suis honnête, je peux dire que je n'active pratiquement jamais cette option dans ma programmation "personnelle".) Mais vous pouvez être sûr que cette option est activée au travail, où notre guide de style (que je écrit) rend obligatoire son utilisation. Et je dirais - je pense que la plupart des programmeurs professionnels diraient - que tout magasin qui ne traite pas les avertissements comme des erreurs dans C se comporte de manière irresponsable, n'adhère pas aux meilleures pratiques de l'industrie communément acceptées.
Les avertissements sont les meilleurs conseils que certains des développeurs C++ les plus qualifiés pourraient intégrer dans une application. Ils valent la peine de rester.
C++, étant un langage complet de Turing, a de nombreux cas où le compilateur doit simplement avoir confiance que vous saviez ce que vous faites. Cependant, il existe de nombreux cas où le compilateur peut réaliser que vous n'aviez probablement pas l'intention d'écrire ce que vous avez écrit. Un exemple classique est les codes printf () qui ne correspondent pas aux arguments, ou les chaînes std :: passées à printf (pas que jamais m'arrive!). Dans ces cas, le code que vous avez écrit n'est pas une erreur. Il s'agit d'une expression C++ valide avec une interprétation valide sur laquelle le compilateur peut agir. Mais le compilateur a une forte intuition que vous avez simplement ignoré quelque chose qui est facile à détecter pour un compilateur moderne. Ce sont des avertissements. Ce sont des choses qui sont évidentes pour un compilateur, utilisant toutes les règles strictes du C++ à sa disposition, que vous auriez pu ignorer.
Désactiver ou ignorer les avertissements, c'est comme choisir d'ignorer les conseils gratuits de personnes plus compétentes que vous. C'est une leçon d'huberis qui se termine soit lorsque vous volez trop près du Soleil et que vos ailes fondent, soit qu'une erreur de corruption de mémoire se produit. Entre les deux, je prendrai la chute du ciel tous les jours!
"Traiter les avertissements comme des erreurs" est la version extrême de cette philosophie. L'idée ici est de résoudre chaque avertissement du compilateur - vous écoutez chaque conseil gratuit et agissez en conséquence. Que ce soit un bon modèle de développement pour vous dépend de l'équipe et du type de produit sur lequel vous travaillez. C'est l'approche ascétique qu'un moine pourrait avoir. Pour certains, cela fonctionne très bien. Pour d'autres, ce n'est pas le cas.
Sur bon nombre de mes applications, nous ne traitons pas les avertissements comme des erreurs. Nous le faisons parce que ces applications particulières doivent être compilées sur plusieurs plates-formes avec plusieurs compilateurs d'âges différents. Parfois, nous constatons qu'il est en fait impossible de fixer un avertissement d'un côté sans qu'il se transforme en avertissement sur une autre plate-forme. Nous sommes donc simplement prudents. Nous respectons les avertissements, mais nous ne nous plions pas en arrière pour eux.
Non seulement la gestion des avertissements améliore le code, mais elle fait de vous un meilleur programmeur. Des avertissements vous parleront de choses qui peuvent vous sembler peu aujourd'hui, mais un jour, cette mauvaise habitude reviendra et vous mordra la tête.
Utilisez le type correct, renvoyez cette valeur, évaluez cette valeur de retour. Prenez le temps et réfléchissez "Est-ce vraiment le bon type dans ce contexte?" "Dois-je retourner ça?" Et le biggie; "Ce code va-t-il être portable pour les 10 prochaines années?"
Prenez l'habitude d'écrire du code sans avertissement en premier lieu.
Les autres réponses sont excellentes et je ne veux pas répéter ce qu'elles ont dit.
Un autre aspect de "pourquoi activer les avertissements" qui n'a pas été correctement abordé est qu'ils aident énormément à la maintenance du code. Lorsque vous écrivez un programme de taille importante, il devient impossible de garder le tout dans votre tête à la fois. Vous avez généralement une ou trois fonctions que vous écrivez et pensez activement, et peut-être un ou trois fichiers sur votre écran auxquels vous pouvez vous référer, mais la majeure partie du programme existe quelque part en arrière-plan et vous devez avoir confiance qu'il continue de travailler.
Avoir des avertissements et les avoir aussi énergiques et en face que possible, vous aide à vous alerter si quelque chose que vous changez crée des problèmes pour quelque chose que vous ne pouvez pas voir.
Prenez par exemple l'avertissement de bruit -Wswitch-enum. Cela déclenche un avertissement si vous utilisez un commutateur sur une énumération et que vous manquez l'une des valeurs d'énumération possibles. C'est quelque chose que vous pourriez penser serait une erreur improbable: vous avez probablement au moins regardé la liste des valeurs d'énumération lorsque vous avez écrit l'instruction switch. Vous pourriez même avoir un IDE qui a généré les options de commutation pour vous, ne laissant aucune place à l'erreur humaine.
Cet avertissement prend tout son sens lorsque, six mois plus tard, vous ajoutez une autre entrée possible à l'énumération. Encore une fois, si vous pensez au code en question, tout ira probablement bien. Mais si cette énumération est utilisée à plusieurs fins différentes et que c'est pour l'une de celles que vous avez besoin de l'option supplémentaire, il est très facile d'oublier de mettre à jour un commutateur dans un fichier que vous n'avez pas touché depuis 6 mois.
Vous pouvez penser aux avertissements de la même manière que vous le pensez aux cas de tests automatisés: ils vous aident à vous assurer que le code est sensé et à faire ce dont vous avez besoin lorsque vous l'écrivez pour la première fois, mais ils aident encore plus à vous assurer qu'il continue de faire ce dont vous avez besoin pendant que vous le produisez. La différence est que les cas de test fonctionnent très étroitement aux exigences de votre code et que vous devez les écrire, tandis que les avertissements fonctionnent largement selon des normes raisonnables pour presque tout le code, et ils sont très généreusement fournis par les boffins qui font les compilateurs.
Les avertissements non fixes seront, tôt ou tard, conduira à des erreurs dans votre code.
Le débogage d'une erreur de segmentation, par exemple, nécessite que le programmeur trace la racine (cause) de l'erreur, qui se trouve généralement à un endroit antérieur dans votre code que la ligne qui a finalement causé l'erreur de segmentation.
Il est très typique que la cause soit une ligne pour laquelle le compilateur avait émis un avertissement que vous avez ignoré, et la ligne qui a provoqué la faute de segmentation la ligne qui a finalement jeté l'erreur.
La correction de l'avertissement conduit à la résolution du problème .. Un classique!
Une démonstration de ce qui précède. Considérez le code suivant:
#include <stdio.h>
int main(void) {
char* str = "Hello world!";
int idx;
// Colossal amount of code here, irrelevant to 'idx'
printf("%c\n", str[idx]);
return 0;
}
qui, une fois compilé avec le drapeau "Wextra" passé à GCC, donne:
main.c: In function 'main':
main.c:9:21: warning: 'idx' is used uninitialized in this function [-Wuninitialized]
9 | printf("%c\n", str[idx]);
| ^
que je pourrais ignorer et exécuter le code de toute façon .. Et puis je serais témoin d'un "grand" défaut de segmentation, comme disait mon professeur d'épicure IP:
Erreur de segmentation
Afin de déboguer ceci dans un scénario du monde réel, on commencerait par la ligne qui cause l'erreur de segmentation et tenterait de tracer quelle est la racine de la cause. Ils devraient rechercher ce qui est arrivé à i et str à l'intérieur de cette quantité colossale de code là-bas ...
Jusqu'à ce qu'un jour, ils se retrouvent dans la situation où ils découvrent que idx est utilisé non initialisé, donc il a une valeur de poubelle, ce qui entraîne l'indexation de la chaîne (bien) au-delà de ses limites, ce qui conduit à un défaut de segmentation.
Si seulement ils n'avaient pas ignoré l'avertissement, ils auraient trouvé le bogue immédiatement!
Traiter les avertissements comme des erreurs n'est qu'un moyen d'autodiscipline: vous compiliez un programme pour tester cette nouvelle fonctionnalité brillante, mais vous ne pouvez pas jusqu'à ce que vous corrigiez les parties bâclées. Il n'y a pas d'informations supplémentaires fournies par Werror, il définit simplement les priorités très clairement:
N'ajoutez pas de nouveau code avant d'avoir résolu les problèmes dans le code existant
C'est vraiment l'état d'esprit qui est important, pas les outils. La sortie de diagnostic du compilateur est un outil. MISRA (pour C embarqué) est un autre outil. Peu importe celui que vous utilisez, mais les avertissements du compilateur sont sans doute l'outil le plus simple que vous pouvez obtenir (c'est juste un indicateur à définir) et le rapport signal/bruit est très élevé. Il n'y a donc aucune raison de ne pas l'utiliser.
Aucun outil n'est infaillible. Si vous écrivez const float pi = 3.14;, La plupart des outils ne vous diront pas que vous avez défini π avec une mauvaise précision, ce qui peut entraîner des problèmes sur la route. La plupart des outils ne lèveront pas les sourcils sur if(tmp < 42), même s'il est communément connu que donner des variables à des noms sans signification et utiliser des nombres magiques est un moyen de catastrophe dans les grands projets. Vous devez comprendre que tout code de "test rapide" que vous écrivez n'est que cela: un test, et vous devez le faire correctement avant de passer à d'autres tâches, tandis que vous voyez toujours ses lacunes. Si vous laissez ces codes tels quels, le débogage si après avoir passé deux mois à ajouter de nouvelles fonctionnalités sera beaucoup plus difficile.
Une fois que vous êtes dans le bon état d'esprit, il est inutile d'utiliser Werror. Le fait d'avoir des avertissements comme avertissements vous permettra de prendre une décision éclairée sur l'opportunité d'exécuter la session de débogage que vous étiez sur le point de démarrer ou de l'abandonner et de corriger les avertissements en premier.
En tant que personne travaillant avec du code C intégré hérité, l'activation des avertissements du compilateur a aidé à montrer beaucoup de faiblesses et de domaines à étudier lors de la proposition de correctifs. Dans gcc utilisant -Wall et -Wextra et même -Wshadow sont devenus vitaux. Je ne vais pas courir tous les dangers, mais je vais en énumérer quelques-uns qui ont surgi et qui ont aidé à montrer les problèmes de code.
Variables laissées pour compte
Celui-ci peut facilement indiquer des travaux inachevés et des domaines qui pourraient ne pas utiliser toutes les variables transmises, ce qui pourrait être un problème. Regardons une fonction simple qui peut déclencher ceci:
int foo(int a, int b)
{
int c = 0;
if (a > 0)
{
return a;
}
return 0;
}
La simple compilation sans -Wall ou -Wextra ne renvoie aucun problème. -Wall vous dira cependant que c n'est jamais utilisé:
foo.c: Dans la fonction ‘foo’:
foo.c: 9: 20: avertissement: variable inutilisée "c" [-Wunused-variable]
-Wextra vous indiquera également que votre paramètre b ne fait rien:
foo.c: Dans la fonction ‘foo’:
foo.c: 9: 20: avertissement: variable inutilisée "c" [-Wunused-variable]
foo.c: 7: 20: avertissement: paramètre inutilisé ‘b’ [-Wunused-parameter] int foo (int a, int b)
Observation variable globale
Celui-ci est un peu dur et n'apparaît pas avant le -Wshadow a été utilisé. Modifions l'exemple ci-dessus pour simplement l'ajouter, mais il se trouve qu'il existe un global avec le même nom qu'un local, ce qui crée beaucoup de confusion lorsque vous essayez d'utiliser les deux.
int c = 7;
int foo(int a, int b)
{
int c = a + b;
return c;
}
Lorsque -Wshadow a été activé, il est facile de détecter ce problème.
foo.c: 11: 9: avertissement: la déclaration de "c" masque une déclaration globale [-Wshadow]
foo.c: 1: 5: remarque: la déclaration fantôme est ici
Format des chaînes
Cela ne nécessite aucun indicateur supplémentaire dans gcc, mais cela a toujours été la source de problèmes dans le passé. Une fonction simple essayant d'imprimer des données, mais ayant une erreur de formatage pourrait ressembler à ceci:
void foo(const char * str)
{
printf("str = %d\n", str);
}
Cela n'imprime pas la chaîne car l'indicateur de formatage est incorrect et gcc vous répondra avec plaisir ce n'est probablement pas ce que vous vouliez:
foo.c: Dans la fonction ‘foo’:
foo.c: 10: 12: avertissement: le format ‘% d’ attend un argument de type ‘int’, mais l’argument 2 a le type ‘const char *’ [-Wformat =]
Ce ne sont que trois des nombreuses choses que le compilateur peut vérifier pour vous. Il y en a beaucoup d'autres comme l'utilisation d'une variable non initialisée que d'autres ont souligné.
Il s'agit d'une réponse spécifique à C, et pourquoi cela est beaucoup plus important pour C que pour toute autre chose.
#include <stdio.h>
int main()
{
FILE *fp = "some string";
}
Ce code se compile avec un avertissement. Ce qui est et devrait être une erreur dans à peu près toutes les autres langues de la planète (à l'exception du langage d'assemblage) sont avertissements en C. Les avertissements en C sont presque toujours des erreurs déguisées. Les avertissements doivent être corrigés et non supprimés.
Avec gcc, nous faisons cela comme gcc -Wall -Werror.
C'était également la raison de la forte répugnance de certains avertissements d'API non sécurisés MS. La plupart des gens qui programment C ont appris la manière difficile de traiter les avertissements comme des erreurs et ce truc est apparu que ce n'était tout simplement pas le même genre de chose et voulait des correctifs non portables.
Les avertissements du compilateur en C++ sont très utiles pour certaines raisons.
1 - Il permet de vous montrer où vous pouvez avoir commis une erreur qui peut impacter le résultat final de vos opérations. Par exemple si vous n'avez pas initialisé une variable ou si vous mettez "=" au lieu de "==" (il y a juste des exemples)
2 - Il permet également de vous montrer où votre code n'est pas conforme au standard du c ++. C'est utile car si le code est conforme à la norme actuelle, il sera facile de déplacer le code dans une autre plateforme par exemple.
En général, les avertissements sont très utiles pour vous montrer où vous avez des erreurs dans votre code qui peuvent affecter le résultat de votre algorithme ou empêcher une erreur lorsque l'utilisateur utilisera votre programme.
Ignorer les avertissements signifie que vous avez laissé du code bâclé qui pourrait non seulement causer des problèmes à l'avenir à quelqu'un d'autre, mais aussi rendre les messages de compilation importants moins remarqués par vous. Plus il y a de sortie du compilateur, moins personne ne le remarquera ou ne le dérangera. Plus propre, mieux c'est. Cela signifie également que vous savez ce que vous faites. Les avertissements sont très peu professionnels, imprudents et risqués.
LES AVERTISSEMENTS DU COMPILATEUR SONT VOTRE AMI (pas de cris, en majuscules pour souligner).
Je travaille sur les anciens systèmes Fortran-77. Le compilateur me dit des choses précieuses: le type de données d'argument ne correspond pas à un appel de sous-routine, en utilisant une variable locale avant qu'une valeur ait été définie dans la variable, si j'ai une variable ou un argument de sous-routine qui n'est pas utilisé. Ce sont presque toujours des erreurs.
Éviter un long post: Quand mon code compile proprement, 97% ça marche. L'autre gars avec qui je travaille compile tous les avertissements, passe des heures ou des jours dans le débogueur, puis me demande de l'aider. Je viens de compiler son code avec les avertissements et de lui dire quoi réparer.
Un avertissement est une erreur qui attend de se produire. Vous devez donc activer les avertissements du compilateur et ranger votre code pour supprimer tout avertissement.
Vous devez toujours activer les avertissements du compilateur car le compilateur peut souvent vous dire ce qui ne va pas avec votre code. Pour ce faire, vous passez -Wall -Wextra au compilateur.
Vous devez généralement traiter les avertissements comme des erreurs, car les avertissements signifient généralement qu'il y a un problème avec votre code. Cependant, il est souvent très facile d'ignorer ces erreurs. Par conséquent, les traiter comme des erreurs entraînera l'échec de la génération, vous ne pouvez donc pas ignorer les erreurs. Pour traiter les avertissements comme des erreurs, passez -Werror au compilateur.
J'ai déjà travaillé pour une grande entreprise (Fortune 50) qui fabriquait du matériel de test électronique.
Le produit de base de mon groupe était un programme MFC qui, au fil des ans, est venu générer littéralement des centaines d'avertissements. Qui ont été ignorés dans presque tous les cas.
C'est un véritable cauchemar quand des bugs se produisent.
Après ce poste, j'ai eu la chance d'être embauché en tant que premier développeur d'une nouvelle startup.
J'ai encouragé une politique "sans avertissement" pour toutes les versions, avec des niveaux d'avertissement du compilateur définis pour être assez bruyants.
Notre pratique consistait à utiliser #pragma warning - Push/disable/pop pour le code que le développeur était sûr était très bien, avec une instruction de journal au niveau du débogage, juste au cas où.
Cette pratique a bien fonctionné pour nous.
Il n'y a qu'un un problème avec le traitement des avertissements comme des erreurs: lorsque vous utilisez du code provenant d'autres sources (par exemple, des bibliothèques micro $ ** t, open source projets), ils n'ont pas fait leur travail correctement, et la compilation de leur code génère tonnes d'avertissements.
J'écris toujours mon code pour qu'il ne génère aucun avertissement ou erreur, et je le nettoie jusqu'à ce qu'il se compile sans générer de bruit étranger. Les ordures avec lesquelles je dois travailler m'épouvante, et je suis étonné quand je dois construire un gros projet et regarder un flux d'avertissements passer par où la compilation ne devrait annoncer que les fichiers qu'elle a traités.
Je documente également mon code parce que je sais que le coût réel des logiciels à vie vient principalement de la maintenance, pas de l'écriture initiale, mais c'est une autre histoire ...
Un avertissement peut signifier une possible erreur sémantique dans le code ou une éventuelle UB. Par exemple. ; Après if(), variable inutilisée, variable globale masquée par local, ou comparaison de signé et non signé. De nombreux avertissements sont liés à l'analyseur de code statique dans le compilateur ou aux violations de la norme ISO détectables au moment de la compilation, qui "nécessitent des diagnostics". Bien que ces événements puissent être légaux dans un cas particulier, ils résulteraient la plupart du temps de problèmes de conception.
Certains compilateurs, par exemple gcc, a une option en ligne de commande pour activer le mode "avertissements en tant qu'erreurs", c'est un outil sympa, quoique cruel, pour éduquer les codeurs débutants.
Le fait que les compilateurs C++ acceptent de compiler du code qui entraîne évidemment un comportement indéfini pas du tout est une faille majeure dans les compilateurs. La raison pour laquelle ils ne résolvent pas cela est que cela casserait probablement certaines versions utilisables.
La plupart des avertissements doivent être des erreurs fatales qui empêchent la génération de se terminer. Les valeurs par défaut pour afficher uniquement les erreurs et faire la construction de toute façon sont erronées et si vous ne les remplacez pas pour traiter les avertissements comme des erreurs et laisser des avertissements, vous vous retrouverez probablement avec le plantage de votre programme et des actions aléatoires.