Salut,

Hé non, bool est un type qui n'accepte que les valeur true et false, mais c'est, avant tout, un type qui est compatible avec n'importe quel autre type numérique.

Ou, plus précisément, n'importe quel type numérique (qu'il s'agisse d'un entier ou d'un réel) peut être automatiquement converti en booléen, selon une règle simple:

• 0 peut être converti en false (faux), quel que soit le type envisagé
• tout ce qui n'est pas équivalent à false vaut true (vrai)

Cette règle permet d'utiliser n'importe quelle valeur numérique dans un test rapide, sous une forme proche de

int i;
/* ... */
if(i){  //false si i == 0, true dans les autres cas
    /* ... */
}

Mais on utilisera encore plus souvent cette possibilité avec des pointeurs:

Type * ptr;
/* ... */
if(ptr){ // false si ptr == nullptr (NULL), true dans les
         // autres cas
    /* ... */
}

Il n'y a donc aucune raison que le compilateur te donne ne serait-ce qu'un avertissement lorsque tu utilise une valeur numérique pour définir un booléen

-
Edité par koala01 20 février 2020 à 8:04:05

> Il n'y a donc aucune raison que le compilateur te donne ne serait-ce qu'un avertissement lorsque tu utilises une valeur numérique pour définir un booléen.

Si quand même. Mettre un littéral autre que 0 ou 1 pour un bool est sûrement une erreur. C'est d'ailleurs une des vérifications faite par clang-tidy.

Pour éviter les erreurs avec perte, on peut utiliser les accolades:

bool x{0}; // ok = false
bool x{1}; // ok = true
bool x{2}; // erreur de compilation

(https://wandbox.org/permlink/v1vO9dQBcaxurDbm)

Mais qui ne retourne aucun avertissement/erreur avant g++-9 (ce qui n'est pas conforme à la norme -_-).

En utilisant les parenthèses cela doit produire un Warning par contre c'est effectivement une erreur utilisant les accolades si l'initialiseur n'est pas 0, 1, false ou true.

Visual C++ 15.9.17 donne :

bool x1(12);   // Avertissement	C4305 'initialisation' : troncation de 'int' à 'bool'
bool x2{13};   // Erreur C2397 la conversion de 'int' en 'bool' requiert une conversion restrictive
bool x3{1};    // Ça c'est OK

>si on peut le contourner aussi facilement.

Pour la "compatibilité" avec le C.

PierrotLeFou a écrit:

En C, on n'a pas le type "bool" et on se sert des astuces mentionnées comme si c'en était.

> Existe-til une option du genre -Wall ou -Wextra comme en C qui donne tous les warning?

Tous les warnings... rigole doucement.

Wall et Wextra n'activent pas tous les avertissements, il y en a une dizaine qui sont utiles mais non activés et encore pas mal qui peuvent être problématique. Il n'y a que clang qui possède un Weverything qui active tout, mais sur lequel il faut repasser derrière pour en désactiver (c'est un peu trop brutal). Le comportement est le même que se soit en C ou en C++, seul la liste des avertissements activé change. Je maintiens un dépôt avec les options par version de compilateur: cpp-compiler-options.

Mais ni clang, ni gcc n'ont d'avertissement pour les booléens. Il n'y a qu'un Wint-in-bool-context dans gcc qui sort entre autres pour des ternaires qui retourne des littéraux autres que 0 et 1: bool b = x ? 2 : 0.

> Je me demande pourquoi on a définit un type 'bool' si on peut le contourner aussi facilement.

Ce n'est pas un contournement, mais une conversion. Comme n'importe quel entier est converti en n'importe qu'elle autre silencieusement. C'est la même chose que dans if(i) avec i un entier de valeur 7, c'est vrai, et aucun compilateur ne va se plaindre.

PierrotLeFou a écrit:

Où se fait la conversion? Lors de la définition ou lors de l'impression?

Lors de la définition de ton booléen, car il ne peut contenir que deux valeurs : 0 pour faux et 1 pour vrai. C'est le principe même de ce type de valeur.

Note que l'on aurait pu choisir n'importe quelle valeur par convention pour représenter les valeurs faux et vrai exactement de la même manière  que l'on a décidé, par convention que 1+1 =2 et non 4...  Nous aurions tout aussi bien pu choisir de représenter faux par 456 et vrai par 999 ... ou l'inverse,

La seule chose, c'est qu'une telle convention aurait été "surprenante" du fait des autres conventions établies (l'absence de quelque chose se représente par le symbole 0, un seul élément se représente par le symbole 1 et le résultat de 1+1 se représente par le symbole 2).

Le standard 99 a introduit

• le type prédéfini _Bool
• l'entête stdbool.h qui fait de bool un synonyme de _Bool

Raison historique :

Le langage C a été conçu avec les pieds comme un langage de cowboys qui savent ce qu'ils font, car ce sont de vrais hommes avec des poils sous le bras, et peuvent se passer de tout. Donc pas besoin de booléens, puisqu'il suffit d'avoir des indicateurs dans des entiers, qui peuvent prendre plusieurs valeurs, c'est encore mieux.

Du coup, dans le code il y a eu des gens qui définissaient (sous la mauvaise influence des boches pascaliens) des type bool, soit comme alias de int ou de char, ou alors des enums, et des constantes true false, à moins que ça soit TRUE FALSE ou encore True False.  et 1 ou -1 pour true ?

Bref, pour peu qu'on importe deux ou trois bibliothèques comme ça, on se retrouve avec des conflits.

Du coup

• introduction du type _Bool qui risque pas trop d'être en conflit.
• et à moins d'avoir la malchance d'utiliser du vieux code pourri, utilisez stdbool.h, qui est le standard recommandé