Discussion :

[bretus]

Bonsoir,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if <expression-booleenne>

Pour la comparaison à true, quand je lis deux "experts confirmés senior" ayant chacun une opinion opposée : Je me dis que ce sont des guerres de chapelle...

Pour ma part, ma principale source de bug immédiat (i.e. avant tests), c'est l'inversion de logique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
if ( estBon ){
     //je traite pas bon
}else{
     // je traite bon
}

Dans les deux cas (estBon) ou (estBon == true), je la ferai toujours quand je somnole... Voir l'inverse dans des conventions de codage ne me ferait pas poser ma démission, mais je rejoins Luc sur un point : Il y a d'autres guerres plus utiles (les noms parlants, limiter la conditionnelle, les imbrications, etc.)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Test de pointeur null

Dommage qu'ils soient écrit si petit les PS d'Emmanuel Deloget à propos des tests de pointeurs null. Par un moment, pour des questions de refactoring (*) vers des smart pointers justement, j'ai rêvé d'un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
/* !!!n'existe pas!!! */
if ( std::is_null( pointeur ) ){
 
}

... avec un comportement homogène sur tout ce qui a sémantique de pointeur (auto_ptr, shared_ptr, etc.)...

A mon avis, le vrai problème n'est pas qu'on test si le pointeur est 0 ou NULL, mais que dans le fond, qu'on ne fasse pas abstraction du fait qu'un pointeur a pour valeur une adresse (d'où les soucis quand les pointeurs sont encapsulés et qu'on doit les dés-encapsuler à coup de get).

Mais bon, on a d'autres problèmes dans la vie!

[Emmanuel Deloget]

Roh mais ne le prend pas comme ça.
Après, le fait de tronquer ==0 et ==nullptr pour garantir la généricité me fait doucement rire ( <-- là oui, cette fois je suis ouvertement méprisant).

Oui mais ça ne devrait pas : dès lors que x possède une conversion, même implicite, vers bool, if les possible d'écrire "if (x)". Ces écritures deviennent par exemple possible :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
  if (stream) // stream est d'un type std::stream quelconque
  if (ptr) // ptr est du type std::unique_ptr<>
  if (my_object) // my_object possède un opérateur de 
                 // conversion implicite vers un type convertible vers bool
                 // ou un operateur explicit bool() en C++11

Alors qu'on a vite des problèmes avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
  if (stream == ????) // qu'est-ce que je mets là ?
  if (my_object == ????) // en C++11, je peux écrire "true" à la place de ????, mais
                         // en C++98, ça risque d'être compliqué: le type réel renvoyé risque 
                         // fort d'être un pointeur sur une fonction membre ; du coup, il faudrait
                         // tester contre NULL ou nullptr, ce qui n'a pas vraiment de sens.

[koala01]

Je voudrais quand même préciser une petite chose

Je suis le premier à ne pas forcément expliciter == true lorsque je dispose d'une expression connue pour être un booléen suffisamment explicite pour me permettre de savoir ce qui est effectivement testé.

Le code if (truc.loadFile("fichier.txt") ) ne me gène absolument pas

Par contre, je trouve que le fait de dire

Il ne faut pas préciser == true

est aussi dangereux que le fait de vouloir forcer l'utilisation de cette forme!

Surtout si cette phrase n'est pas argumentée.

Qu'il suffise de voir les réactions aux arguments que j'ai donné et qui tiennent pourtant la route (meme si je n'y souscrit pas forcément) pour se rendre compte à quel point il est difficile de trouver un consensus sur la chose !!!

Ce que je voulais mettre en évidence, c'est qu'il n'y a aucune raison à être catégorique ni dans un sens, ni dans l'autre : après tout, comme je l'ai fait remarquer, le fait d'écrire == true ne prend qu'une demi seconde et n'use pas forcément le clavier

Par contre, lorsque quelqu'un débute (comprenez : avant qu'il ne se soit habitué au fait que le == true soit implicite ) il me semble réellement exagéré d'essayer de lui interdire cette écriture!

Il y a en effet neuf chances sur dix pour qu'un débutant trouve plus explicite de l'ajouter dans ses premiers codes mais pour qu'il s'habitue, après avoir pris un peu de bouteille, à passer à la forme implicite, c'est dans la courbe d'apprentissage!

Ce qui m'a fait hurler à la base n'est pas tant en le fait que bretus ait fait la remarque, mais bien qu'il l'ait faite sans apporter de justifications, et donc, même si sa remarque était correcte et non agressive, qu'il donnait l'impression de faire une remarque arbitraire de "tu ne dois jamais ajouter == true".

C'est d'autant plus vrai que, à voir la demande originale, gregg1 est tout en bas de la courbe d'apprentissage et que la particularité qui consiste à considérer == true comme implicite ne doit etre exprimée que bien après (et l'on se comprend sur le terme, hein ) qu'il ait assimilé la différence entre la comparaison et l'affectation

[cob59]

Oui mais ça ne devrait pas : dès lors que x possède une conversion, même implicite, vers bool, if les possible d'écrire "if (x)". Ces écritures deviennent par exemple possible :

En c++, il y a toujours une marge entre ce qu'il est possible de faire et ce qu'il est recommandé de faire. Appeler une méthode booléenne (du genre isEmpty()) sur un objet sera toujours préférable à une conversion implicite vers un bool, en terme de clarté du code. Donc selon tes exemples :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
if (stream.good())
if (ptr!=nullptr)
if (object.isValid())
 
// C'est tout de suite plus lisible, non ?

Sur l'argument de la généricité, j'ai du mal à m'imaginer quel serait le «rôle algorithmique» du if dans le code suivant, avec des types T très disparates (string, map, int, void*, ...). Qu'attend-on du if de la fonction foo<T> ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
template <class T>
void foo(const T& v)
{
  if (v) {
    ...
  }
}

[screetch]

Le code if (truc.loadFile("fichier.txt") ) ne me gène absolument pas

loadFile() retourne en fait non pas un booleen qui indique le succès mais un code d'erreur. Ton code if devient inversé.

[oodini]

Oui mais ça ne devrait pas : dès lors que x possède une conversion, même implicite, vers bool, if les possible d'écrire "if (x)". Ces écritures deviennent par exemple possible

C'est ça qui ne devrait pas être fait : reposer sur une conversion implicite (une habitude du C).

Du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
int i = 10;
while (i)
{
   i--
}

Il vaut mieux faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
int i = 10;
while (i > 0)
{
   i--
}

[screetch]

ca ne devrait pas, il faut, ce n'est pas très argumenté (c'est pas forcément une critique, surtout un constat) comme la plupart des posts précédents. Bref, tout le monde il a raison, c'est une question de préférence, les coups et les douleurs ca se discute pas.

et sinon, ce qui est dommage/pas sympa c'est surtout d'essayer de convaincre, je dirai plutôt convertir vu la tournure religieuse que prend la conversation.

[oodini]

Les arguments sont données dans mon premier post sur ce sujet.

[JolyLoic]

PS1 : si tu me trouve un peu "dur", il faut mettre en rapport les termes "idiotismes" et "utilisés par les idiots", et comme je l'utilise beaucoup...

Je ne vois absolument pas pourquoi les mettre en rapport. Ce sont deux mots qui n'ont pas grand'chose à voir l'un avec l'autre, et idiotisme n'est absolument pas connoté péjorativement, la racine "idio" venant juste du mot idiome.

En c++, il y a toujours une marge entre ce qu'il est possible de faire et ce qu'il est recommandé de faire. Appeler une méthode booléenne (du genre isEmpty()) sur un objet sera toujours préférable à une conversion implicite vers un bool, en terme de clarté du code. Donc selon tes exemples :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
if (stream.good())
if (ptr!=nullptr)
if (object.isValid())
 
// C'est tout de suite plus lisible, non ?

Je ne suis pas certain que ce soit le cas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
while(stream >> nom >> prenom >> age);
// ou
while((stream >> nom >> prenom >> age).good());

Je trouve la seconde écriture bien moins claire, avec des parenthèses qui rendent difficile de voir à quoi est appliqué la fonction good.

Sinon, je vais systématiquement expliciter la constante pour un type entier (ne serait-ce que parce que dans la moitié du code, une valeur 0 signifie ok, et une valeur non nulle représente un code d'erreur, et dans l'autre moitié du code, l'entier est à considéré comme un booléen qui s'ignore, avec 0 valant false, tout le reste valant true).

Pour un booléen, je ne vais jamais expliciter la constante, je trouve que ça alourdi inutilement, surtout quand l'expression se complexifie

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
if (a || (b && c))
if (a==true || (b && c))
if (a || (b==true && c))
if (a || (b&& c==true))
if (a==true || (b && c==true))
if (a==true || (b==true && c==true))
if ((a==true || (b==true && c==true)==true)==true)

Pour un pointeur, j'oscille... Au début, je mettais des ==NULL (que je rêvais de remplacer par des ==nullptr). Mais comme cette écriture ne marche pas bien avec des shared_ptr, je me suis habitué à ne mettre que le pointeur.

[cob59]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
// Notation abrégée
while(stream >> nom >> prenom >> age) {
}
// Notation explicite
while(stream.good()) {
    stream >> nom >> prenom >> age;
}

[Luc Hermitte]

Et tu boucles deux fois sur la dernière ligne. (on en parle dans la FAQ).

@Loic, je te pique ton exemple, je l'adore.

[Steph_ng8]

Et tu boucles deux fois sur la dernière ligne. (on en parle dans la FAQ).

Euh, j'ai reparcouru rapidement le section de la FAQ sur les flux, mais je n'ai rien vu concernant ce double bouclage.
Peux-tu développer, s'il-te-plaît ?

[Luc Hermitte]

C'était pourtant là.

http://cpp.developpez.com/faq/cpp/?p...s#FICHIERS_eof

[Steph_ng8]

Ah ok, je pensais que tu parlais de la dernière ligne de code...
Au temps pour moi...