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.

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

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

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