Cette question peut sembler stupide, mais pourquoi 0
évalue-t-elle false
et toute autre valeur [entière] true
est la plupart des langages de programmation?
Comparaison de chaîne
Comme la question semble un peu trop simple, je vais en expliquer un peu plus: tout d’abord, cela peut sembler évident à tout programmeur, mais pourquoi n’y aurait-il pas un langage de programmation - il se peut qu’il en existe, mais pas n'importe lequel. J'ai utilisé - où 0
évalue true
et toutes les autres valeurs [entier] à false
? Cette remarque peut sembler aléatoire, mais j’ai quelques exemples où cela aurait pu être une bonne idée. Tout d'abord, prenons l'exemple de la comparaison tridirectionnelle de chaînes, je prendrai strcmp
comme exemple l'exemple de C : tout programmeur essayant d'utiliser C comme première langue peut être tenté d'écrire le code suivant:
if (strcmp(str1, str2)) { // Do something... }
Depuis strcmp
return, 0
qui évalue à false
quand les chaînes sont égales, ce que le programmeur a essayé de faire échoue lamentablement et il ne comprend généralement pas pourquoi au début. Si elle avait été 0
évaluée à la true
place, cette fonction aurait pu être utilisée dans sa plus simple expression - celle ci-dessus - pour comparer l'égalité et les vérifications appropriées pour -1
et 1
n'auraient été effectuées qu'en cas de besoin. Nous aurions considéré le type de retour comme bool
(dans notre esprit je veux dire) la plupart du temps.
De plus, introduisons un nouveau type sign
, qui prend juste des valeurs -1
, 0
et 1
. Cela peut être très pratique. Imaginez qu'il y ait un opérateur de vaisseau spatial en C ++ et que nous le voulions std::string
bien (bon, il y a déjà une compare
fonction, mais l'opérateur de vaisseau spatial est plus amusant). La déclaration serait actuellement la suivante:
sign operator<=>(const std::string& lhs, const std::string& rhs);
S'il avait 0
été évalué true
, l'opérateur du vaisseau spatial n'existerait même pas, et nous aurions pu le déclarer operator==
ainsi:
sign operator==(const std::string& lhs, const std::string& rhs);
Cela operator==
aurait traité la comparaison à trois voies à la fois, et pourrait toujours être utilisé pour effectuer le contrôle suivant tout en pouvant vérifier quelle chaîne est lexicographiquement supérieure à l'autre le cas échéant:
if (str1 == str2) { // Do something... }
Gestion des erreurs anciennes
Nous avons maintenant des exceptions, donc cette partie ne s’applique qu’aux anciennes langues où il n’en existait pas (C par exemple). Si nous regardons la bibliothèque standard de C (et celle de POSIX également), nous pouvons voir avec certitude que les fonctions maaaaany retournent en 0
cas de succès et que tout nombre entier sinon. J'ai malheureusement vu des gens faire ce genre de choses:
#define TRUE 0
// ...
if (some_function() == TRUE)
{
// Here, TRUE would mean success...
// Do something
}
Si nous réfléchissons à notre façon de penser en programmation, nous avons souvent le schéma de raisonnement suivant:
Do something
Did it work?
Yes ->
That's ok, one case to handle
No ->
Why? Many cases to handle
Si nous y repenions, il aurait été logique de mettre la seule valeur neutre 0
, à yes
(et c'est ainsi que fonctionnent les fonctions de C), alors que toutes les autres valeurs peuvent être là pour résoudre les nombreux cas de la no
. Cependant, dans tous les langages de programmation que je connais (sauf peut - être quelques langues expérimentales ésotériques), qui yes
évalue à false
dans un if
état, alors que tous les no
cas à évaluer true
. Il existe de nombreuses situations où "ça marche" représente un cas alors que "ça ne marche pas" représente plusieurs causes probables. Si nous y réfléchissons de la sorte, avoir 0
évalué à true
et au reste false
aurait eu beaucoup plus de sens.
Conclusion
Ma conclusion est essentiellement ma question initiale: pourquoi avons-nous conçu les langages où 0
sont false
et sont les autres valeurs true
, en prenant en compte mes quelques exemples ci-dessus et peut-être d'autres que je n'ai pas pensé?
Suivi: Il est agréable de voir qu'il existe de nombreuses réponses avec de nombreuses idées et autant de raisons possibles pour que cela se produise. J'aime à quel point vous semblez passionné. Au départ, j’avais posé cette question par ennui, mais comme vous paraissiez si passionné, j’ai décidé d’aller un peu plus loin et de demander pourquoi le choix booléen pour 0 et 1 sur Math.SE :)
strcmp()
n’est pas un bon exemple pour true ou false, car il renvoie 3 valeurs différentes. Et vous serez surpris lorsque vous commencerez à utiliser un shell, où 0 signifie vrai et tout le reste faux.if true ; then ... ; fi
: oùtrue
est une commande qui renvoie zéro et qui demandeif
à être exécutée...
.bool
Réponses:
0
estfalse
parce qu'ils sont tous les deux des éléments nuls dans les semi- communes . Même s'il s'agit de types de données distincts, il est logique de procéder à la conversion entre eux, car ils appartiennent à des structures algébriques isomorphes.0
est l'identité pour l'addition et zéro pour la multiplication. Cela est vrai pour les entiers et les rationnels, mais pas pour les nombres à virgule flottante IEEE-754:0.0 * NaN = NaN
et0.0 * Infinity = NaN
.false
est l'identité pour booléenne XOR (⊻) et zéro pour booléenne et (∧). Si les booléens sont représentés par {0, 1} - l'ensemble des entiers modulo 2 -, vous pouvez considérer comme addition sans retenue et comme multiplication.""
et[]
sont une identité pour la concaténation, mais il y a plusieurs opérations pour lesquelles elles ont un sens comme zéro. La répétition en est une, mais la répétition et la concaténation ne sont pas distribuées et ces opérations ne forment donc pas un semiring.De telles conversions implicites sont utiles dans les petits programmes, mais dans l’ensemble, elles peuvent rendre les programmes plus difficiles à raisonner. Un des nombreux inconvénients de la conception linguistique.
la source
nil
à la fois la liste vide[]
et lafalse
valeur dans Common Lisp; existe-t-il une tendance à fusionner les identités provenant de différents types de données?) Vous devez toujours expliquer pourquoi il est naturel de considérer faux comme une identité additive et vrai comme une identité multiplicative. et non l'inverse. N'est-il pas possible de considérertrue
comme l'identifiantAND
et le zéroOR
?true
est aussi l'identité et le zéro des semirings (booléens et / ou). Il n'y a aucune raison, à part la convention, à considérerfalse
est plus proche de 0 quetrue
.Parce que les maths fonctionnent.
Traditionnellement, les programmes C ont des conditions comme
plutôt que
parce que le concept de zéro étant équivalent à faux est bien compris.
la source
Comme d'autres l'ont dit, le calcul est venu en premier. C'est pourquoi 0 est
false
et 1 esttrue
.De quelles mathématiques parlons-nous? Algèbres booléennes datant du milieu des années 1800, bien avant l'arrivée des ordinateurs numériques.
Vous pouvez également dire que la convention est issue de la logique propositionnelle , qui est même plus ancienne que les algèbres booléennes. C'est la formalisation de beaucoup de résultats logiques que les programmeurs connaissent et aiment (
false || x
égauxx
,true && x
égauxx
, etc.).Fondamentalement, nous parlons d'arithmétique sur un ensemble avec deux éléments. Pensez à compter en binaire. Les algèbres booléennes sont à l'origine de ce concept et de son fondement théorique. Les conventions de langages comme C ne sont qu’une application simple.
la source
true = 1
. Ce n'est pas tout à fait exact, cartrue != 0
ce n'est pas exactement la même chose. Une des raisons (et non la seule) pour laquelle il faut éviter les comparaisons telles queif(something == true) { ... }
.Je pensais que cela avait à voir avec "l'héritage" de l'électronique, et aussi l'algèbre booléenne, où
0
=off
,negative
,no
,false
1
=on
,positive
,yes
,true
strcmp renvoie 0 lorsque les chaînes sont égales, cela a à voir avec sa mise en œuvre, car ce qu'il fait est de calculer la "distance" entre les deux chaînes. Que 0 soit également considéré comme faux est simplement une coïncidence.
Il est logique de renvoyer 0 en cas de succès, car 0 signifie dans ce cas aucune erreur et tout autre chiffre constituerait un code d'erreur. Utiliser n'importe quel autre numéro pour réussir aurait moins de sens puisque vous n'avez qu'un seul code de réussite, alors que vous pouvez avoir plusieurs codes d'erreur. Vous utilisez "Cela a-t-il fonctionné?" comme si l'expression de déclaration et dire 0 = oui aurait plus de sens, mais l'expression est plus correctement "Est-ce que quelque chose s'est mal passé?" et ensuite vous voyez que 0 = non a beaucoup de sens. Penser
false/true
n'a pas vraiment de sens ici, comme c'est en faitno error code/error code
.la source
0
poursuccess/no error
est la seule chose qui est logique quand d' autres entiers représentent les codes d'erreur. Cela0
arrive aussi à représenterfalse
dans d' autres cas ne compte pas vraiment, puisque nous ne parlons pas de vrai ou faux tout ici;)strcmp()
calcul de la distance est assez bonne. Si cela avait été appelé,strdiff()
ceif (!strdiff())
serait très logique.Comme expliqué dans cet article , les valeurs
false
ettrue
ne doivent pas être confondues avec les entiers 0 et 1, mais peuvent être identifiées avec les éléments du corps de Galois (champ fini) de deux éléments (voir ici ).Un champ est un ensemble avec deux opérations qui satisfont certains axiomes.
Les symboles 0 et 1 sont classiquement utilisés pour désigner les identités additives et multiplicatives d'un champ car les nombres réels sont aussi un champ (mais pas un nombre fini) dont les identités sont les nombres 0 et 1.
L'identité additive est l'élément 0 du champ, tel que pour tout x:
et l'identité multiplicative est l'élément 1 du champ, tel que pour tout x:
Le corps fini de deux éléments n'a que ces deux éléments, à savoir l'identité additive 0 (ou
false
) et l'identité multiplicative 1 (outrue
). Les deux opérations de ce champ sont le XOR logique (+) et le ET logique (*).Remarque. Si vous inversez les opérations (XOR est la multiplication et AND est l'addition), la multiplication n'est pas distributive sur l'addition et vous n'avez plus de champ. Dans un tel cas, vous n'avez aucune raison d'appeler les deux éléments 0 et 1 (dans n'importe quel ordre). Notez également que vous ne pouvez pas choisir l'opération OR à la place de XOR: quelle que soit la façon dont vous interprétez OR / AND comme addition / multiplication, la structure résultante n'est pas un champ (tous les éléments inverses n'existent pas comme l'exigent les axiomes du champ).
En ce qui concerne les fonctions C:
strcmp
calcule la différence entre deux chaînes. 0 signifie qu'il n'y a pas de différence entre deux chaînes, c'est-à-dire que deux chaînes sont égales.Les explications intuitives ci-dessus peuvent aider à mémoriser l'interprétation des valeurs de retour, mais il est encore plus simple de consulter la documentation de la bibliothèque.
la source
Vous devriez considérer que les systèmes alternatifs peuvent également être des décisions de conception acceptables.
Coques: 0 l'état de sortie est vrai, non-zéro est faux
L'exemple de shells traitant un statut de sortie 0 comme étant true a déjà été mentionné.
La raison en est qu'il y a un moyen de réussir, mais de nombreuses façons d'échouer. Par conséquent, utiliser 0 comme valeur spéciale signifiant "pas d'erreur" est pragmatique.
Ruby: 0 est comme n'importe quel autre numéro
Parmi les langages de programmation "normaux", il existe des valeurs aberrantes, telles que Ruby, qui traitent 0 comme une valeur vraie.
Le raisonnement est que seulement
false
etnil
devrait être faux. Pour beaucoup de novices Ruby, c'est un piège. Cependant, dans certains cas, il est agréable que 0 soit traité comme n'importe quel autre nombre.Cependant, un tel système ne fonctionne que dans une langue capable de distinguer les booléens d'un type distinct des nombres. Au début de l'informatique, les programmeurs travaillant avec le langage assembleur ou le langage machine brut n'avaient pas ce luxe. Il est probablement naturel de considérer 0 comme l'état "vide" et de définir un bit sur 1 comme indicateur lorsque le code détecte que quelque chose s'est passé. Par extension, la convention élaborée établissait que zéro était traité comme faux et que les valeurs non nulles devenaient vraies. Cependant, il n'est pas nécessaire que ce soit comme ça.
Java: les nombres ne peuvent pas être traités comme des booléens
En Java,
true
etfalse
sont les seules valeurs booléennes. Les nombres ne sont pas des booléens et ne peuvent même pas être convertis en booléens ( spécification du langage Java, section 4.2.2 ):Cette règle évite simplement la question - toutes les expressions booléennes doivent être explicitement écrites dans le code.
la source
if (thing === 0)
, ce n'est tout simplement pas cool.0
soittrue
(comme tous les autres entiers) dans un langage dynamique. Il m’arrivait parfois d’attraper un0
problème en essayant d’attraperNone
en Python, et cela peut parfois être assez difficile à repérer.if [ 0 ] ; then echo this executes ; fi
. La valeur de données fausses est une chaîne vide, et un mensonge testable est un état de terminaison manqué d'une commande, qui est représenté par un non -Zero.Avant d'aborder le cas général, nous pouvons discuter de vos contre-exemples.
Comparaisons de chaînes
La même chose vaut pour beaucoup de sortes de comparaisons, en fait. De telles comparaisons calculent une distance entre deux objets. Lorsque les objets sont égaux, la distance est minimale. Ainsi, lorsque la "comparaison réussit", la valeur est 0. Mais en réalité, la valeur de retour de
strcmp
n'est pas un booléen, c'est une distance et c'est ce qui piège les programmeurs ignorantsif (strcmp(...)) do_when_equal() else do_when_not_equal()
.En C ++, nous pourrions reconcevoir
strcmp
pour renvoyer unDistance
objet, qui se substitueoperator bool()
à vrai lorsque 0 (mais vous seriez alors piqué par un ensemble de problèmes différent). Ou simplement, C a juste unestreq
fonction qui retourne 1 quand les chaînes sont égales, et 0 sinon.Appels API / code de sortie du programme
Ici, vous vous souciez de la raison pour laquelle quelque chose a mal tourné, car cela poussera les décisions vers le haut en erreur. Lorsque les choses réussissent, vous ne voulez rien savoir de particulier, votre intention est réalisée. La valeur de retour doit donc transmettre cette information. Ce n'est pas un booléen, c'est un code d'erreur. La valeur d'erreur spéciale 0 signifie "pas d'erreur". Le reste de la plage représente les erreurs significatives localement que vous devez traiter (y compris 1, ce qui signifie souvent "erreur non spécifiée").
Cas général
Cela nous laisse avec la question: pourquoi les valeurs booléennes
True
etFalse
communément représentées avec 1 et 0, respectivement?Eh bien, outre l'argument subjectif "on se sent mieux de cette façon", voici quelques raisons (subjectives aussi) auxquelles je peux penser:
Analogie avec un circuit électrique. Le courant est activé pour 1s et désactivé pour 0s. J'aime avoir (1, oui, vrai, activé) ensemble et (0, non, faux, désactivé), plutôt qu'un autre mélange
initialisations de la mémoire. Quand je suis
memset(0)
un groupe de variables (que ce soit des ints, des floats, des bools), je veux que leur valeur corresponde aux hypothèses les plus conservatrices. Par exemple, ma somme est initialement égale à 0, le prédicat est faux, etc.Peut-être que toutes ces raisons sont liées à mon éducation - si on m'avait appris à associer 0 à True dès le début, j'aurais choisi l'inverse.
la source
bool
du tout.int
labool
dans de nombreux langages de programmation. La comparaison et la gestion des erreurs ne sont que des exemples d’endroits où il serait logique de le formuler autrement.D'un point de vue général, vous parlez de trois types de données très différents:
Un booléen. La convention mathématique en algèbre booléenne est d'utiliser 0 pour
false
et 1 pourtrue
, il est donc logique de suivre cette convention. Je pense que cette façon de faire est également plus logique intuitivement.Le résultat de la comparaison. Cela a trois valeurs:
<
,=
et>
(notez qu'aucun d'entre eux esttrue
). Pour eux, il est judicieux d'utiliser les valeurs -1, 0 et 1, respectivement (ou, plus généralement, une valeur négative, zéro et une valeur positive).Si vous voulez vérifier l’égalité et que vous n’avez qu’une fonction qui effectue une comparaison générale, je pense que vous devriez la rendre explicite en utilisant quelque chose comme
strcmp(str1, str2) == 0
. L'utilisation!
de cette situation est source de confusion car elle traite une valeur non booléenne comme s'il s'agissait d'un booléen.Aussi, gardez à l'esprit que la comparaison et l'égalité ne doivent pas nécessairement être la même chose. Par exemple, si vous commandez des personnes en fonction de leur date de naissance, elles
Compare(me, myTwin)
devraient revenir0
, maisEquals(me, myTwin)
devraient y revenirfalse
.Le succès ou l'échec d'une fonction, éventuellement avec des détails sur ce succès ou cet échec. Si vous parlez de Windows, ce type est appelé
HRESULT
et une valeur non nulle n'indique pas nécessairement un échec. En fait, une valeur négative indique un échec et un succès non négatif. La valeur de réussite est très souventS_OK = 0
, mais il peut également s'agir par exempleS_FALSE = 1
, ou d'autres valeurs.La confusion vient du fait que trois types de données logiquement très différents sont représentés sous la forme d’un seul type de données (un entier) en C et dans d’autres langues et que vous pouvez utiliser un entier dans une condition. Mais je ne pense pas qu'il serait logique de redéfinir booléen pour rendre l'utilisation de certains types non booléens dans des conditions plus simples.
En outre, considérons un autre type souvent utilisé dans une condition de C: un pointeur. Là-bas, il est naturel de traiter un
NULL
pointeur (représenté par0
) commefalse
. Il serait donc également plus difficile de travailler avec des indicateurs en suivant votre suggestion. (Bien que, personnellement, je préfère explicitement comparer les pointeurs avecNULL
, au lieu de les traiter comme des booléens.)la source
Zéro peut être faux car la plupart des processeurs ont un indicateur ZÉRO qui peut être utilisé pour créer une branche. Il enregistre une opération de comparaison.
Voyons pourquoi.
Certains psuedocode, car le public ne lit probablement pas assemblage
c-source appelle des appels de boucle simples wibble 10 fois
certains prétendent assembler pour cela
c- source une autre simple boucle appelle wibble 10 fois
certains prétendent assembler pour ce cas
un peu plus c source
et l'assemblée
voyez comme c'est court?
un peu plus c source
et l'assembly (supposons un compilateur marginalement intelligent qui peut remplacer == 0 sans comparaison)
Essayons maintenant une convention de true = 1
un peu plus c source #define TRUE 1 int foo = TRUE; if (foo == TRUE) wibble ()
et l'assemblée
voyez combien le cas avec true est vrai?
Très tôt, les processeurs avaient de petits ensembles de drapeaux attachés à l'accumulateur.
Pour vérifier si a> b ou a = b prend généralement une instruction de comparaison.
Permet de reformuler cela. Sur certains processeurs plus anciens, vous n'avez pas eu à utiliser une instruction de comparaison pour accumulateur égale à ZERO, ou un accumulateur inférieur à zéro.
Maintenant, voyez-vous pourquoi zéro pourrait être faux?
Veuillez noter que ceci est du code pseudo et qu'aucun jeu d'instructions réel ne ressemble à cela. Si vous connaissez l'assemblée, vous savez que je simplifie beaucoup les choses ici. Si vous savez quelque chose sur la conception du compilateur, vous n'avez pas besoin de lire cette réponse. Tous ceux qui connaissent le déroulage en boucle ou la prédiction de branche, la classe avancée se trouve dans la salle 203.
la source
if (foo)
elleif (foo != 0)
devrait générer le même code et, d’autre part, vous montrez que le langage d’assemblage que vous utilisez contient en fait des opérandes et des tests booléens explicites. Par exemplejz
signifiejump if zero
. En d'autres termesif (a == 0) goto target;
. Et la quantité n'est même pas testée directement; la condition est convertie en un indicateur booléen qui est stocké dans un mot machine spécial. C'est en fait plus commecpu.flags.zero = (a == 0); if (cpu.flags.zero) goto target;
jz
instruction mais nonjnz
? (ou tout autre ensemble asymétrique d'instructions conditionnelles)Il y a beaucoup de réponses qui suggèrent qu'une correspondance entre 1 et true est rendue nécessaire par certaines propriétés mathématiques. Je ne peux pas trouver une telle propriété et suggère que c'est une convention purement historique.
Dans un champ à deux éléments, nous avons deux opérations: addition et multiplication. Nous pouvons mapper les opérations booléennes sur ce champ de deux manières:
Traditionnellement, nous identifions Vrai avec 1 et Faux avec 0. Nous identifions AND avec * et XOR avec +. Ainsi, OR est une addition saturante.
Cependant, nous pourrions tout aussi facilement identifier True avec 0 et False avec 1. Ensuite, nous identifions OR avec * et XNOR avec +. Ainsi, AND est une addition saturante.
la source
Étrangement, zéro n'est pas toujours faux.
En particulier, les conventions Unix et Posix définissent
EXIT_SUCCESS
0 (etEXIT_FAILURE
1). En fait, il s’agit même d’une convention C standard !Donc, pour les shells Posix et les appels système exit (2) , 0 signifie "success", ce qui est intuitivement plus vrai que faux.
En particulier, le shell
if
veut qu'un retour de processusEXIT_SUCCESS
(c'est-à-dire 0) suive sa branche "then"!Dans Scheme (mais pas dans Common Lisp ni dans MELT ) 0 et nil (c'est-
()
à- dire dans Scheme) sont vrais, puisque la seule valeur fausse est#f
Je suis d'accord, je suis nerveux!
la source
C est utilisé pour la programmation de bas niveau proche du matériel, domaine dans lequel vous devez parfois basculer entre les opérations au niveau du bit et les opérations logiques, sur les mêmes données. Etre obligé de convertir une expression numérique en booléen juste pour effectuer un test encombrerait le code.
Vous pouvez écrire des choses comme:
plutôt que
Dans un exemple isolé, ce n’est pas si grave, mais cela sera pénible.
De même, conversez des opérations. Il est utile que le résultat d'une opération booléenne, comme une comparaison, produise simplement un 0 ou un 1: Supposons que nous voulions définir le troisième bit d'un mot en fonction de
modemctrl
l'activation du bit de détection de porteuse:Ici, nous devons avoir le
!= 0
pour réduire le résultat de l'&
expression biwise à0
ou1
, mais comme le résultat n'est qu'un entier, nous évitons d'avoir à ajouter un casting ennuyeux pour convertir davantage booléen en entier.Bien que le C moderne ait maintenant un
bool
type, il conserve la validité d'un code comme celui-ci, à la fois parce que c'est une bonne chose et à cause de la rupture massive avec compatibilité ascendante qui serait autrement causée.Un autre exemple où C est lisse: tester deux conditions booléennes en tant que commutateur à quatre directions:
Vous ne pouvez pas enlever cela au programmeur C sans vous battre!
Enfin, C sert parfois de langage d'assemblage de haut niveau. Dans les langages d'assemblage, nous n'avons pas non plus de types booléens. Une valeur booléenne est juste un bit ou une valeur zéro par rapport à une valeur différente de zéro dans un emplacement de mémoire ou un registre. Un entier zéro, un booléen zéro et l'adresse zéro sont tous testés de la même manière dans les jeux d'instructions en langage assembleur (et peut-être même à virgule zéro). La ressemblance entre le langage C et le langage assembleur est utile, par exemple lorsque C est utilisé comme langage cible pour la compilation d'un autre langage (même celui qui a des booléens fortement typés!)
la source
Une valeur booléenne ou vérité n'a que 2 valeurs. Vrai et faux.
Ceux-ci ne devraient pas être représentés sous forme d'entiers, mais sous forme de bits (0 et 1).
Dire n'importe quel autre entier à côté de 0 ou 1 n'est pas faux est une déclaration déroutante. Les tables de vérité traitent des valeurs de vérité, pas des entiers.
D'une valeur de vérité prospective, -1 ou 2 briseraient toutes les tables de vérité et toute logique booléenne associée à celles-ci.
La plupart des langues ont généralement un
boolean
type qui, lorsqu'il est converti en un type de nombre tel que entier, révèle que false doit être converti en une valeur entière égale à 0.la source
TRUE
ouFALSE
. Jamais je n'ai dit - peut-être je l'ai fait, mais ce n'était pas prévu - les nombres entiers étaient vrais ou faux, je leur ai demandé pourquoi ils évaluent à quel que soit le résultat lorsqu'ils sont convertis en booléens.En fin de compte, vous parlez de casser le langage principal car certaines API sont de mauvaise qualité. Les API Crappy ne sont pas nouvelles et vous ne pouvez pas les réparer en cassant le langage. C’est un fait mathématique que 0 est faux et 1 vrai, et toute langue qui ne le respecte pas est fondamentalement brisée. La comparaison à trois voies est un créneau et il n’ya pas d’affaire qui convertit implicitement son résultat
bool
car elle renvoie trois résultats possibles. Les anciennes API C ont simplement une terrible gestion des erreurs et sont également bloquées, car C n’a pas les fonctionnalités de langage nécessaires pour ne pas avoir d’interfaces terribles.Notez que je ne dis pas cela pour les langues qui n'ont pas de conversion implicite-> booléenne implicite.
la source
+
symbole OR. Donc, par exempleabc + a'b'c
signifie(a and b and c) or (a and (not b) and (not c))
.