Discussion :

[Greggg1]

[NOTA By KOALA]Ceci est un message original tiré de la discussion aide pour un exo dont est parti cette digression sur l'usage explicte de true, NULL ou nullptr dans les expressions booléennes.

Merci de ne répondre à ce message que dans la discussion d'origine
Salut à tous ,

Je suis un grand débutant en C++ et j'ai un petit probleme avec mon exo :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
 
#include <cstdlib>
#include <iostream>
using namespace std;
 
int main(int argc, char *argv[])
{
    cout<<"bonjour\n";
 
    char S ; //sexe de la personne
    int A ; // age de la personne 
    bool droit ; //initialiser a vrai si la personne a droit a la carte
 
    cout<<"Saisir l'age et le sexe de la personne : " "\n" ;
 
    cin>>S>>A ;
 
    if (S=='F') 
    {   
        if (A>=60) 
         {
             droit=true ;
         }
         else
         {
             droit=false ;
         }          
    } 
    else 
    {
        if (S=='H') 
        {   
        if (A>=65) 
         {
             droit=true ;
         }
         else 
         {
             droit=false ;
         }          
    }  
    if (droit=false) 
    {
        cout<<"Vous n'avez pas le droit a la carte vermeil" "\n" ;
    }
    if (droit=true)
    { 
        cout<<"Vous avez le droit a la carte vermeil" "\n" ;
    }                     
    system("PAUSE");
    return EXIT_SUCCESS;
}
}

Si vous ne comprenez pas le probleme je vous explique en esperant que vous puissiez m'aider .

Greggg1.

[bretus]

Bonsoir,

2) "unBooleen == true" est d'un intérêt limité...

[oodini]

2) "unBooleen == true" est d'un intérêt limité...

C'est plus clair. Et ça a l'intérêt de rappeller que c'est un booléen, le C++ n'appliquant pas un typage fort dans les tests booléens.

[Greggg1]

2) "unBooleen == true" est d'un intérêt limité...

D'abord merci pour ta reponse mais en fait en cours le prof nous l'a fait marquer en algo et en tp il a voulu qu'on le passe en C++ donc on doit garder la structure qu'il nous a filer et ne rien changer ...

Ce que je comprends c'est que, que je mette n'importe quel sexe et n'importe quel âge, j'ai toujours "vous n'avez pas le droit a la carte vermeil ".

en esperant que tu puisse m'aider .

Greggg1.

[bretus]

D'abord merci pour ta reponse mais en fait en cours le prof nous l'a fait marquer en algo et en tp il a voulu qu'on le passe en C++ donc on doit garder la structure qu'il nous a filer et ne rien changer ...

C'est marrant, le miens nous avait clairement expliqué que si on comparait un booléen à "true", on était bon pour la bulle...

C'est plus clair. Et ça a l'intérêt de rappeller que c'est un booléen, le C++ n'appliquant pas un typage fort dans les tests booléens.

Le résultat est pourtant sous vos yeux, ça apporte beaucoup d'injecter des instructions inutiles...

[koala01]

2) "unBooleen == true" est d'un intérêt limité...

Hé bien, je ne suis pas du tout d'accord...

Le seul intéret d'écrire unBoolee au lieu de unBooleen == true est d'éviter d'user le clavier, par contre, unBooleen == true est tout de suite beaucoup plus clair pour celui qui lit le code ( tout comme unPointeur != NULL est beaucoup plus clair que unPointeur )

Il en faut pas oublier qu'un code est beaucoup plus souvent lu / compilé /exécuté -- parfois très longtemps après avoir été écrit par quelqu'un d'autre -- qu'il n'est écrit / modifié !!!

Le résultat sera de toutes manières identique, mais si on peut être sur que meme une personne à moitié endormie lisant le code n'aura aucun doute sur l'objectif d'une ligne de code (on dit que le code est "auto commenté" ), c'est toujours cela de gagné

[bretus]

Le résultat sera de toutes manières identique, mais si on peut être sur que meme une personne à moitié endormie lisant le code n'aura aucun doute sur l'objectif d'une ligne de code (on dit que le code est "auto commenté" ), c'est toujours cela de gagné

Heu, pour l'auto-documentation du code, je préfère les noms qui puent le booléen et renforce le sens (isAllowed, isMarked, hasChildren, canMove, etc...)

Après, je pense que c'est des questions de goût (perso, je tombe là dessus, ça me perturbe)

La plupart du temps, quand je lutte à comprendre un code, c'est la sémantique des variables qui pose souci. Tu ne crois pas que si on se demande si une variable est un booléen à la lecture, alors le nom n'est pas assez parlant?

[koala01]

Heu, pour l'auto-documentation du code, je préfère les noms qui puent le booléen et renforce le sens (isAllowed, isMarked, hasChildren, canMove, etc...)

Mais, meme avec des noms corrects (qu'il faut utiliser en priorité), je ne vois absolument pas pourquoi se priver d'une information correcte... == true va prendre royalement une demi seconde à écrire, et ne va pas user le clavier

Après, je pense que c'est des questions de goût (perso, je tombe là dessus, ça me perturbe)

Je trouve au contraire que c'est beaucoup plus clair...

Ceci dit, je t'accorde cependant qu'il faut essentiellement que ce soit cohérent dans l'ensemble du projet

Je ne vois aucun mal à ne pas le mettre, pour autant, et c'est cela qui importe, qu'il ne soit alors mis nulle part!

Mais c'est donc typiquement le genre de chose qui doit être clairement indiqué dans les "coding rules" à respecter par l'équipe de développement!

Par contre, il est tout aussi aberrant de dire "ne le met pas" que de dire "mets le" si c'est sans expliquer pourquoi, et, surtout, si cela implique qu'il apparaisse, ou non, selon l'humeur du codeur

La plupart du temps, quand je lutte à comprendre un code, c'est la sémantique des variables qui pose souci. Tu ne crois pas que si on se demande si une variable est un booléen à la lecture, alors le nom n'est pas assez parlant?

Cela, je te l'accorde sans problème, mais je n'ai absolument pas traité de ce sujet

Le problème, c'est que, en généralisant "il est inutile d'ajouter un == true", on peut en arriver à un code proche de

Code :

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

1
2
3
4
5
6
7
8
if (numberOfElement)
{
   /*...*/
}
else
{
   /*...*/
}

qui sera tout à fait valide, et qui, pour autant que tu aies pensé "je dois faire la distinction entre le fait d'avoir au moins un élément et le fait de ne pas en avoir" feras sans doute ce que tu attend de ces lignes!!!

Le fait est que, pour ces lignes, on se serait attendu à avoir la comparaison de nuberOfElement avec une valeur ( < 0, == 5, ou que sais-je ? )

Il en va donc de la cohérence du code au niveau du projet : si, pour n'importe quel test ne portant pas sur des booléens, on s'attend à avoir un opérateur de comparaison, il n'y a aucune raison pour travailler différemment avec les booléens

[Steph_ng8]

Bonjour,
Personnellement, depuis l'arrivée du type bool (oui, je parle aussi du C), je considère qu'un test doit toujours être une expression booléenne.
Or il se trouve qu'un booléen est une expression booléenne.

Donc, quand j'écris du code, je ne compare jamais un booléen avec true ou false.
En revanche, quand je veux vérifier qu'un nombre, un caractère ou un pointeur est/n'est pas nul, je préfère le comparer avec la constante anonyme adéquate.
C'est cohérent, tout ça ?

Mais j'y pense, si on considère que l'on doit toujours comparer un booléen à true/false (peu importe les raisons), ça veut dire également qu'il faudrait comparer les expressions booléennes avec ces constantes !
Ah bah si, lorsque l'on utilise une expression dans un test, c'est comme si on créait une variable temporaire qui prendrait la valeur du résultat de l'expression, puis qu'on utilisait cette variable pour le test...
Dans ce cas, où est la différence ?

D'une manière plus générale, si on ne peut pas être sûr du type d'une variable, on ne peut pas non plus être sûr du type du résultat d'une expression.
Sauf si on a une connaissance sur le type de retour de l'expression, mais c'est comme avoir une connaissance sur le type de la variable...

Dernière question, histoire de pimenter un peu le débat...
En quoi la comparaison d'une variable avec true/false prouve que cette variable est bien un booléen ?
Ah, les conversions implicites...

[cob59]

Tout dépend de la manière dont on se représente l'instruction if :

Code :

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

if ( <booléen> ) {} // #1

ou

Code :

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

if ( <expression booléenne> ) {} // #2

Quand je lis un code, je vois tous les if comme #1, c'est à dire que la présence d'une expression booléenne dans le if n'est pas une fin en soi, mais une médiation par laquelle on obtient un résultat booléen, et donc le modèle #1.

if(myBoolean==true) est donc superflu.
Par contre if(mInt!=0) et if(myPtr!=nullptr) lèvent l'ambiguïté(vis-à-vis du lecteur bien sûr, pas du compilo) suscitée par des conversions implicites int->bool et T*->bool, ils me semblent donc justifiés.

[Steph_ng8]

Par contre if(mInt!=0) et if(myPtr!=nullptr) lèvent l'ambiguïté(vis-à-vis du lecteur bien sûr, pas du compilo) suscitée par des conversions implicites int->bool et T*->bool, ils me semblent donc justifiés.

Je peux me tromper, mais je crois que tout le monde est d'accord là-dessus.
Le débat se pose juste sur les booléen.

[Emmanuel Deloget]

if(myBoolean==true) est donc superflu.
Par contre if(mInt!=0) et if(myPtr!=nullptr) lèvent l'ambiguïté(vis-à-vis du lecteur bien sûr, pas du compilo) suscitée par des conversions implicites int->bool et T*->bool, ils me semblent donc justifiés.

Dans le même temps, les écritures if (mInt) et if (myPtr) sont suffisamment idiomatiques (et suffisamment correcte) pour que le lecteur du code soit capable de les comprendre. Le standard C++ est construit pour permettre ces écritures idiomatique (elles l'étaient bien avant la standardisation du C).

Ceci dit, ce n'est pas le débat ; l'OP a obligation de suivre les indications de son prof (qu'elles soient bonnes ou moins bonnes (franchement, les pro, vous avez déjà vu des normes de programmation qui soient à 100% logiques ? déjà, qui dit norme de programmation dit "la personne qui l'a écrite ne connait pas suffisamment son métier pour être sûr de ce qu'elle fait))

[cob59]

Je peux me tromper, mais je crois que tout le monde est d'accord là-dessus.
Le débat se pose juste sur les booléen.

J'expliquais seulement pourquoi les notations if(myInt!=0) et if(myPtr!=nullptr) ne justifiaient pas - à mon sens - l'emploi de if(myBool==true), en réaction à ce message :

unBooleen == true est tout de suite beaucoup plus clair pour celui qui lit le code ( tout comme unPointeur != NULL est beaucoup plus clair que unPointeur )

@Emmanuel Deloget
Ca m'a surtout l'air d'être un idiotisme hérité du C, où l'on ne résonne pas en fonction de types booléens, et dont il serait bon de se débarrasser. Enfin, m'est avis.

[Emmanuel Deloget]

@Emmanuel Deloget
Ca m'a surtout l'air d'être un idiotisme hérité du C, où l'on ne résonne pas en fonction de types booléens, et dont il serait bon de se débarrasser. Enfin, m'est avis.

Ouch.

Ta science de la programmation est si importante que je ne peux que m’effacer devant ton avis si tranché.

Je ne suis pas forcément très doué dans ce langage dont on parle (le ++C, je crois), donc je n'oserais pas m'interposer devant la force de tes affirmations.

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...

PS2 : un "idiotime" qui a résisté à 30 ans d'utilisations, il faudrait peut-être se poser la question de voire si, par hasard, il ne serait pas autre chose qu'un "idiotisme".

PS3 : au cas où, et je dis probablement ça à tord et à travers, si on change le type de la variable testée, ne faut-il pas aussi changer la valeur contre laquelle elle est testée (alors que la condition cherche à évaluer la validité de l'opérande testée, et non pas si cet opérande, dont le type peut changer, est égal à 0) ? En bref, si tu écrit if (x == 0), qu'est-ce que tu encapsules, et de quelle manière est-ce que ça peut casser si le type de x change ? Quelle différence par rapport à if (x) dans le cas ou le type de x est changé d'un type scalaire vers un type composé ? La question se pose notamment si on transforme un pointeur (X*) en pointeur intelligent (par exemple std::unique_ptr<X>). Que se passe-t-il alors ? Est-ce que unique_ptr<X> définit un opérateur de conversion vers X* ou vers un type intégral qui lui permet d'être testé contre 0 ? Qu'en est-il des streams du C++ ?

PS4: ce n'est pas parce que Java fait mal les choses que les autres langages doivent aussi faire les choses aussi mal (les comparaisons étant le point très, très, très faible de Java du point de vue d'un développeur).

[cob59]

Roh mais ne le prend pas comme ça.
Allez, un bisou.

Je n'ai rien contre les idiotismes, mais en l’occurrence je trouve que celui-ci n'est approprié qu'au langage C, où "bool" n'existe pas et où les if() évaluent donc forcément autre chose que des booléens. Je ne sais pas si je suis clair...
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).
[EDIT] En plus il existe boost::initialized_value pour ce genre de problème.

[Luc Hermitte]

s/idiotisme/idiomatisme ?

Sinon, je trouve le test explicite à true ridicule, vu que lui-même est un autre booléen (même si temporaire/rvalue). Et du coup, pourquoi ne pas partir sur if (...((((est_toto() == true) == true) == true ...) ?

Pareil. Quand je parle, je ne regarde pas si "la vaisselle est faite est vrai".
Donc + 1 pour des variables bien nommées. Enforçons d'abord ça avant de pinailler sur des détails aussi peu pertinents que "== true". C'est le genre de règle que je trouve au contraire dangereuse car elle encourage à continuer avec des noms de variables mal choisis -- même combat avec le SESE en C++ qui encourage à avoir des fonctions de 3 kilomètres au lieu d'encourager respecter le SRP.

[screetch]

et pourquoi pas "retirer" les booléens qui n'expriment pas souvent beaucoup, et les remplacer par des enum?

c'est pas forcément lié au débat courant (encore que..)
mais une focntion qui fait

Code :

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

1
2
3
4
5
6
7
8
bool loadFile(const std::string& filename)
{
...
}
 
if(loadFile())
{
}

n'est pas très parlant (même si on se doute que ca renvoie "true" si ca a reussi, encore que...)

alors que

Code :

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

1
2
3
if(loadFile() == true)
{
}

est... euh, en fait, tout aussi naze.

Alors que

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
enum LoadResult
{
  Load_Error = 0,
  Load_Success = 1
};
LoadResult loadFile(const std::string& filename)
{
...
}
 
if(loadFile() == Load_Success)
{
}

aaah, là on commence a parler =) non?
je prône (un peu) de ne pas utiliser les booléens du tout (mais je ne le hurle pas sur les toits et des fois j'en mets dans mon code pour me faire passer pour quelqu'un de normal)

[Luc Hermitte]

Plusieurs fois, c'est une question que je m'étais posée, mais pour une autre raison : deux fonctions, une qui prenait un booléen (hasFailed), et l'autre son contraire (hasSucceeded). Et bien sûr, la première appelle la seconde.
Le bug est vite arrivé.

Du coup, je préfère parfois (quand pour des raisons obscures je n'utilise pas des exceptions ici) une fonction (booléenne) qui marcherait ainsi:

Code c++ :

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

1
2
3
4
5
6
7
struct Load {
    enum Result { KO, OK, MAX__};
};
// le nom est mauvais ...
bool successes(Load::Result r) {return r == Load::OK; }
...
if (successes(load_file("foo.bar"))) {...

[screetch]

oui c'est la principale utilsiation des enum a la place des booleens, dans les paramètres, car si on lit l'appel d'une methode lambda:

Code :

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

update(true, false);

eeeuh, oui... alors... le premier true c'est pour...

alors que

Code :

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

update(UpdateMode_Recursive, UpdateMode_NoInterpolate);

ah la on comprend a quoi servent les paramètres

(j'aime bien le coup du hasSucceeded, hasFailed )

[cob59]

+1 screetch
C'est d'ailleurs un principe très utilisé sous Qt, auquel on peut sûrement reprocher certaines choses, mais pas d'être illisible.