FAQ -> liste d'initialisation

J'ai surtout l'impression que tu crois que je râle... :)

Un warning est un warning: "Ca m'empeche pas de compiler, mais je suis pas sur que ce que j'ai compris correspond bien a ce que tu veux faire".
C'est bien pour cette raison, qu'en général, on pousse les warnings au maximum, en leur faisant la chasse comme si c'était des erreurs (d'ailleurs on peut tout à fait dire au compilo, si warning, considere ca comme une erreur, ce qui devrait être la règle par défaut à mon avis).

Maintenant, trop de warnings poussent plus les programmeurs à baisser leur quantité par tweaking des options de compilation, plutôt que de les résoudre. Je me souviens d'un projet Eclipse par exemple, ou un mec avait viré les warning "Natural Language String" parce que dans son code ca lui faisait 300 warnings à chaque fichier...

Et certains compilateur mettront un warning sur une liste d'initialisation sans effet de bord (simple application des paramètres du constructeur par exemple), simplement parceque l'ordre n'est pas celui de déclaration, hors ce warning est complètement inutile ! Alors qu'il est absoluement nécessaire dès qu'il y a effet de bord possible (code appelé...) voire même qu'il soit carrément une erreur si il y a un comportement clairement indéfini !

Mais à ce moment là, il faut bien plus faire prendre conscience au programmeur qu'il est bien plus constructif de prendre un avertissement en compte que de diminuer le niveau d'avertissement...

Sinon, la loi de murphy nous indique que, s'il y a une c... à faire, on trouvera toujours quelqu'un pour la faire :P

Et comme les petits ruisseaux font les grands fleuves:

On commence par ne pas avertir que la liste d'initialisation sera pris dans l'ordre parce que c'est un comportement prévu par la norme

On continue en ne prévenant pas par un "1 est toujours vrai" quand on voit un code du genre de

Code:

---

if( 1 || fonction())

---

(poussé à l'extrème, je te l'accorde :P)

car, finalement, ce n'est qu'un comportement prévu par la norme :D

Sauf que, dans ce cas, fonction() est sensée modifier une valeur... mais elle n'est jamais appelée :P

Et au final, on obtient une application qui ne fait pas la moitié de ce qu'elle doit faire, ou qui le fait mal, ou qui ne réagit pas comme elle le devrait...

Alors, où arrêter le raisonnement du "c'est prévu par la norme" :question:

Autant se dire que, si le compilateur travaille différemment de ce que le codage laisse supposer, car les modifications à apporter ne sont, en définitive jamais si importantes que cela pour prendre les avertissements en compte, et s'assurer par ce simple fait que le programmeur aura pris conscience de son mauvais comportement...

Apres tout, un avertissement sur une liste d'initialisation gérée dans un autre ordre, ca nécessite quoi:question:

A peine le déplacement d'un terme, qui peut parfaitement être résolu par un couper/coller... Enorme comme travail, non 8O:nono::calim2:

Mais, au moins, on s'assure que si l'initialisation fait appel à un comportement à effet de bord, ce sera d'office pris en compte ;)

J'ai vaguement l'impression qu'on ne parle pas de la même chose....

La norme indique ce que doit faire le code généré par le compilateur....
Le compilateur essaye de traduire ce que veut faire le codeur.

1. Si il n'y a aucune ambiguité possible... par exemple:

Code:

---

1 2 3 4 5

class A { int a, b; A() : b(0), a(0) {} };

---

Pourquoi mettre un warning ?


2. Si il y a ambiguité, mais "qui n'a pas l'air" de prêter à conséquence, le compilateur va faire un choix pour nous, et DOIT nous avertir que ceci est dangereux... par exemple:

Code:

---

1 2 3 4 5

class A { int a,b; A(int n) : b(n++), a(n++) {} };

---

On doit être rappelé que a va être construit avant b ! Le codeur, pour supprimer le warning, n'a qu'à inverser l'ordre de la liste d'initialisation...

3. Si il y a un comportement indéfini, le compilateur DOIT pondre une erreur.

Code:

---

1 2 3 4 5

class A { int a,b; A(int n) : b(a++), a(n) {} };

---

Et ensuite ? tu préfères un warning dans le cas 1 ? Pourquoi ?
Pour éviter que si quelqu'un modifie le code plus tard il n'ai des problêmes ? Mais dans ce cas il tombera dans le cas 2 (warning) ou 3 (error) à la compilation... Je continue de ne pas voir l'interêt du warning pour le cas 1 !

Accroche toi à tes baskets, car je vais te faire la preuve par l'absurde du problème d'avertissements trop "ciblés" ;)

Je reprend tes deux codes:

Code:

---

1 2 3 4 5 6 7

class A { int a; int b; int c;   inline A(int p1, int p2) : c(p1), b(p2), a(0) {}//aucun avertissement };

---

Code:

---

1 2 3 4 5 6 7

class A { int a; int b; int c;   inline A(int p1, int p2) : c(p1), b(p2), a(p1++) {}//avertissement à cause de p1++ };

---

je modifie à peine le premier pour les assembler en un seul

Code:

---

1 2 3 4 5 6 7 8 9 10

class A { int a; int b; int c; public: /* pas d'avertissement */ inline A(int p1, int p2, int p3) : c(p1), b(p2), a(p3) {} /* avertissement */ inline A(int p1, int p2) : c(p1), b(p2), a(p1++) {} };

---

Maintenant, met toi à la place de celui qui fera la c... d'après la loi de Murphy:

Citation:

---

Mais je ne comprend absolument pas pourquoi mon :furieux: de compilateur me sort un avertissement pour le deuxième constructeur et pas pour le premier alors que la liste d'initialisation est présentée exactement sous la même forme
:arrow::arrow: le compilateur ne sait pas ce qu'il dit ::arrow: je ne fais pas attention à ses avertissements (ou pire: je les désactive)

---

Et, résultat des courses, il s'étonnera que dans le code

Code:

---

1 2 3

A obj1(4,3,5); A obj2(4,3);

---

ne fournisse pas deux objets ayant des valeurs identiques...

Ce que je veux dire, en définitive, l'avantage de fournir un avertissement sur un cas qui "pourrait potentiellement poser problème" permet de se garder à meilleure distance des cas qui posent "réellement problème".

Si, dés le départ, tu "drille" le codeur à être attentif, dans sa liste d'initialisation, à l'ordre dans lequel il initialise les membres, même si, dans le contexte, cela ne pose aucun problème, il prendra l'habitude d'y être attentif.

Et donc, il finira par s'éloigner du fameux cas "peau de banane" d'une initialisation en utilisant une fonction à effet de bord...

Tout le monde sera alors gagnant :D