question rapide sur les warning

Pour vous, doit on virer ton les warning d'une compilation? et donc les considérer comme une erreur?

Je configure mon compilateur est au niveau super sensible
Je n'active pas l'option warning = erreur
mais de toutes façons, je ne continue pas tant qu'il y a des warnings

Je suis tenté de dire oui.
Si un warning est affiché, c'est pas pour rien, il faut en tenir compte, c'est pas pour les chiens. Bien souvent les warnings sont sur ces broutilles, des erreurs d'inattention, ça ne te tuera pas de les corriger.
Si vraiment il y a certains warnings que tu ne peux pas éviter, soit, on pourrait alors préconiser un réglage du compilo pour inhiber ces warnings là et toujours bénéficier de la levée de tous les autres, toujours dans l'idée d'avoir une compilation "sans warning".

Et comme on dit toujours, un bon réglage de ton compilo t'évitera déjà pas mal de bugs

bonjour,

assez d'accord, quand le temps et le client le permettent j essaye de tout virer c'est toujours plus tranquilisant, excepter sous visual studio les trucs du genre sprintf deprecated utiliser sprintf_s

Pour la plupart ok.
Mais certain j'hésite.
Par exemple l'utilisation de int et uint dans un calcul.
Un warning est donné, et je le trouve important de le garder. Justement parce qu'un cast pour virer le warning n'est peut être pas la solution...


Je trouve que ça permet de donner une trace d'un problème potentielle. Et cela bien mieux qu'un commentaire que l'on ne lira pas :aie:

et changer l une des 2 variables en signée ou non pour etre conforme ?

Citation:

---

Envoyé par BainE

et changer l une des 2 variables en signée ou non pour etre conforme ?

---

parce que cast de -1 en unsigned int est si vite arrivé :roll:

Citation:

---

Envoyé par Mongaulois

Par exemple l'utilisation de int et uint dans un calcul.
Un warning est donné, et je le trouve important de le garder. Justement parce qu'un cast pour virer le warning n'est peut être pas la solution...

---

Et garder un warning n'est pas forcément le plus malin non plus, cf. par ex quelques explications.
Et un peu de code pour illustrer :

Code:

---

1 2 3 4 5 6

BOOST_AUTO_TEST_CASE( IntegralPromotion ) { int i = -1; unsigned int j = 0; BOOST_CHECK( i < j ); }

---

Produit le fameux warning :

Code:

---

warning C4018: '<' : signed/unsigned mismatch

---

Et donne comme résultat :

Code:

---

error in "IntegralPromotion": check i < j failed

---

(le test échoue, i n'est pas < à j)

Citation:

---

Envoyé par Mongaulois

parce que cast de -1 en unsigned int est si vite arrivé :roll:

---

Pas besoin de transtypage, le mécanisme de promotion/conversion sur les entiers s'en charge très bien. :roll:

MAT.

Citation:

---

Envoyé par Mat007

Et garder un warning n'est pas forcément le plus malin non plus, cf. par ex quelques explications.

---

C'est typiquement mon exemple en faite ;)
Ce n'est pas toujours évident de le résoudre. ET surtout pas toujours nécessaires...
Je trouve que garder le warning est utile pour garder la trace de ce risque potentiel

Salut,

pour ma part, il n'y a pas grand chose qui m'énerve plus que les gens qui laissent traîner des warnings, surtout dans le cadre d'un travail collaboratif.
Cà rend rapidement les traces du compilo illisibles; une tonne de warning "mineurs" préexistants (pour autant qu'un warning puisse etre considéré comme mineur), type de flood qui arrive très vite, peut masquer un warning important introduit par des modifications ultérieures (genre, les miennes) ...
Donc pour ma part, je compile autant que possible systématiquement en -Wall -Werror

-Wall n'est pas suffisant.
L'idéal c'est -std=c++98 -Wall -Wextra -pedantic

ou -std=g++98 pour avoir les extensions GNU, comme les tableaux de taille variable.

En C, on ajoute -Wwrite-strings, mais je ne sais jamais si c'est déjà implicite en C++ ou non...

okok. Merci des reponses.
Le warning est le sous-fifre de error, il faut donc les éradiquer.

Je mettrais résolu un peu plus tard, au cas où quelqu'un à autre chose à ajouter.

Merci a tous