J'ai ces deux petits programmes:

C

#include <stdio.h>
int main()
{
    if (5) {
        printf("true\n");
    }
    else {
        printf("false\n");
    }

    return 0;
}

Java

class type_system {
   public static void main(String args[]) {
       if (5) {
           System.out.println("true");
       }
       else {
           System.out.println("false");
       }
   }
}

qui rapporte le message d'erreur:

type_system.java:4: error: incompatible types: int cannot be converted to boolean
       if (5) {
           ^
1 error

Ma compréhension

Jusqu'ici, j'ai compris cet exemple comme une démonstration des différents systèmes de types. C est plus faiblement typé et permet la conversion de int en booléen sans erreur. Java est plus fortement typé et échoue, car aucune conversation implicite n'est autorisée.

Par conséquent, ma question: Où ai-je mal compris les choses?

Ce que je ne cherche pas

Ma question n'est pas liée au style de codage incorrect. Je sais que c'est mauvais, mais je m'interroge sur la raison pour laquelle C l'autorise et non sur Java. Par conséquent, je m'intéresse au système de types de la langue, en particulier à sa force.

1. C et Java sont des langues différentes

Le fait qu'ils se comportent différemment ne devrait pas être terriblement surprenant.

2. C ne fait aucune conversion de intàbool

Comment pourrait-il? C n’avait même pas de booltype à convertir avant 1999 . C a été créé au début des années 1970 et en iffaisait partie avant même d'être C, à l'époque où il s'agissait simplement d'une série de modifications apportées à B ¹ .

ifn'était pas simplement NOPen C depuis près de 30 ans. Il agissait directement sur les valeurs numériques. Le verbiage dans la norme C ( lien PDF ), même plus d'une décennie après l'introduction de bools en C, spécifie toujours le comportement de if(p 148) et ?:(p 100) en utilisant les termes "inégalé à 0" et "égal à 0 "plutôt que les termes booléens" true "ou" false "ou quelque chose de similaire.

Idéalement, ...

3. ... les chiffres correspondent exactement aux instructions du processeur.

JZet JNZsont vos instructions d’assemblage x86 de base pour les branchements conditionnels. Les abréviations sont " J UMP si Z ero" et " J UMP si N ot Z ero". Les équivalents de la PDP-11, où C est issue, sont BEQ( " B ranch si EQ uel ") et BNE(" B ranch si N ot E Qual").

Ces instructions vérifient si l'opération précédente a généré un zéro ou non et saute (ou non) en conséquence.

4. Java accorde beaucoup plus d'importance à la sécurité que jamais ²

Et, soucieux de la sécurité, ils ont décidé que la limitation ifà booleans valait le coût (tant pour la mise en œuvre d'une telle restriction que pour les coûts d'opportunité qui en résultent).

^1. B n'a même pas de types du tout. Les langues d'assemblage ne le sont généralement pas non plus. Pourtant, les langages B et d’assemblage parviennent très bien à gérer les branches.

^2. Selon les mots de Dennis Ritchie, décrivant les modifications prévues à B qui sont devenues C (c'est moi qui souligne):

... il semblait qu'un schéma de frappe était nécessaire pour gérer les caractères et l'adressage d'octets, et pour préparer le matériel à virgule flottante à venir. D'autres problèmes, notamment la sécurité des types et la vérification de l'interface, ne semblaient pas aussi importants qu'ils ne le sont devenus par la suite.

C 2011 projet en ligne

6.8.4.1 L' ifinstruction

Contraintes

1 L'expression de contrôle d'une ifinstruction doit être de type scalaire.

Sémantique

2 Dans les deux formes, le premier sous-dénombrement est exécuté si l'expression est différente de 0. Le elsesous-dénombrement est exécuté si l'expression est égale à 0. Si le premier sous-dénombrement est atteint via une étiquette, le deuxième Non exécuté.

3 An elseest associé au précédent lexical le plus proche si cela est autorisé par la syntaxe.

Notez que cette clause spécifie uniquement que l'expression de contrôle doit avoir un type scalaire ( char/ short/ int/ long/ etc.), Pas spécifiquement un type booléen. Une branche est exécutée si l'expression de contrôle a une valeur différente de zéro.

Comparez cela avec

Spécification du langage Java SE 8

14.9 L' ifinstruction

L' ifinstruction permet l'exécution conditionnelle d'une instruction ou le choix conditionnel de deux instructions, en exécutant l'une ou l'autre mais pas les deux.

    IfThenStatement :
        si (  Expression ) Statement

    IfThenElseStatement :
        if ( Expression ) StatementNoShortIf else Statement

    IfThenElseStatementNoShortIf :
        if ( Expression ) StatementNoShortIf else StatementNoShortIf

L' expression doit avoir le typeboolean ou Boolean, sinon une erreur de compilation se produit.

Java, OTOH, requiert spécifiquement que l'expression de contrôle dans une ifinstruction ait un type booléen.

Donc, il ne s'agit pas de typage faible ou fort, mais de ce que chaque définition de langage respective spécifie comme expression de contrôle valide.

modifier

En ce qui concerne la raison pour laquelle les langues sont différentes à cet égard, plusieurs points:

1. C est dérivé de B, qui est un langage "sans type" - en gros, tout était un mot de 32 à 36 bits (selon le matériel), et toutes les opérations arithmétiques étaient des opérations entières. Le système de type de C était verrouillé un à un, de sorte que ...

2. C n'avait pas de type booléen distinct jusqu'à la version 1999 du langage. C a simplement suivi la convention B consistant à utiliser zéro pour représenter falseet non-zéro pour représenter true.

3. Java, qui date de 20 à 20 ans, a été conçu spécifiquement pour remédier à certaines des faiblesses de C et C ++. Nul doute que renforcer la restriction sur ce qui pourrait être une expression de contrôle dans une ifdéclaration en faisait partie.

4. Il n'y a aucune raison de s'attendre à ce que deux langages de programmation fassent les choses de la même manière. Même des langages aussi proches que C et C ++ divergent de manière intéressante, de sorte que vous pouvez avoir des programmes C juridiques qui ne sont pas des programmes C ++ légaux, ou qui sont des programmes C ++ légaux mais avec une sémantique différente, etc.

Beaucoup de réponses semblent cibler l'expression d'affectation incorporée qui se trouve dans l'expression conditionnelle. (Bien que ce soit un piège potentiel connu, ce n'est pas la source du message d'erreur Java dans ce cas.)

C’est peut-être parce que le PO n’a pas publié le message d’erreur réel et que le ^curseur pointe directement sur le= opérateur de l'affectation.

Cependant, le compilateur pointe vers le = car c'est l'opérateur qui produit la valeur finale (et donc le type final) de l'expression que voit le conditionnel.

Il se plaint de tester une valeur non booléenne, avec le type d'erreur suivant:

erreur: types incompatibles: int ne peut pas être converti en booléen

Le test des entiers, bien que parfois pratique, est considéré comme un piège que les concepteurs de Java ont choisi d'éviter. Après tout, Java a un vrai type de données booléen , ce que C n’a pas (il n’a pas de type booléen) .

Ceci s'applique également aux pointeurs de test de C pour la valeur null / non-null via if (p) ...et if (!p) ..., ce que Java ne permet pas non plus de demander à un opérateur de comparaison explicite d'obtenir le booléen requis.

types incompatibles: int ne peut pas être converti en booléen

Je suis intéressé à savoir pourquoi C le permet et java pas. Par conséquent, je m'intéresse au système de types de la langue, en particulier à sa force.

Votre question comporte deux parties:

Pourquoi ne pas convertir Java intà boolean?

Cela revient à dire que Java doit être aussi explicite que possible. Il est très statique, très "en face" avec son système de types. Les éléments qui sont automatiquement typés dans d'autres langues ne le sont pas, en Java. Vous devez int a=(int)0.5aussi écrire . La conversion floaten intperdrait des informations; même que la conversion inten booleanet serait donc sujette à erreur. En outre, ils auraient dû spécifier beaucoup de combinaisons. Bien sûr, ces choses semblent évidentes, mais elles avaient pour but de pécher par excès de prudence.

Oh, et comparé à d’autres langages, Java était extrêmement précis dans ses spécifications, car le bytecode n’était pas simplement un détail d’implémentation interne. Ils devraient spécifier toutes les interactions, précisément. Énorme entreprise.

Pourquoi n'accepte ifpas d'autres types queboolean ?

ifpourrait parfaitement être défini comme autoriser d’autres types que boolean. Il pourrait avoir une définition disant que les éléments suivants sont équivalents:

• true
• int != 0
• String avec .length>0
• Toute autre référence d'objet non null(et non Booleanavec une valeur false).
• Ou même: toute autre référence d'objet non nullet dont la méthode Object.check_if(inventée par moi juste pour cette occasion) retourne true.

Ils ne l'ont pas fait; ils n'en avaient pas vraiment besoin et ils voulaient qu'il soit aussi robuste, statique, transparent, facile à lire, etc. Pas de fonctionnalités implicites. De plus, l'implémentation serait assez complexe, je suis sûr, de devoir tester chaque valeur dans tous les cas possibles, donc les performances ont peut-être joué un petit facteur (Java était jadis peu utilisé sur les ordinateurs de cette journée; rappelez-vous Il n’existait pas de compilateurs JIT avec les premières versions, du moins pas sur les ordinateurs que j’avais utilisés à l’époque).

Raison plus profonde

Une raison plus profonde pourrait bien être le fait que Java a ses types primitifs, son système de types est donc partagé entre des objets et des primitives. Peut-être que s'ils avaient évité cela, les choses se seraient passées autrement. Avec les règles données dans la section précédente, ils devraient définir la véracité de chaque primitive de manière explicite (puisque les primitives ne partagent pas une super classe et qu'il n'y a pas de définition précise nullpour les primitives). Cela se transformerait en un cauchemar, rapidement.

Perspective

Eh bien, et au final, c'est peut-être une préférence des concepteurs de langage. Chaque langue semble s'y frayer un chemin ...

Par exemple, Ruby n'a pas de types primitifs. Tout, littéralement tout, est un objet. Ils ont beaucoup de facilité à s'assurer que chaque objet a une certaine méthode.

Ruby recherche la vérité sur tous les types d'objets que vous pouvez lui lancer. Chose intéressante, il n’a toujours pas de booleantype (car il n’a pas de primitives) et il n’a pas non plus de Booleanclasse. Si vous demandez quelle classe a la valeur true(facilement disponible avec true.class), vous obtenez TrueClass. Cette classe a effectivement des méthodes, à savoir les 4 opérateurs pour les booléens ( | & ^ ==). Ici, ifconsidère sa valeur falsey si et seulement si c'est falseou nil(le nullde Ruby). Tout le reste est vrai. Donc, 0ou ""sont les deux vrais.

Il aurait été trivial pour eux de créer une méthode Object#truthy?pouvant être mise en œuvre pour n’importe quelle classe et de restituer une vérité individuelle. Par exemple, String#truthy?aurait pu être implémenté pour être vrai pour des chaînes non vides, ou autre chose. Ils ne l’ont pas fait, même si Ruby est l’antithèse de Java dans la plupart des départements (typage dynamique de canards avec mixin, réouverture de classes, etc.).

Ce qui pourrait surprendre un programmeur Perl habitué à $value <> 0 || length($value)>0 || defined($value)la vérité. Etc.

Entrez SQL avec sa convention qui, nullà l'intérieur de n'importe quelle expression, la rend automatiquement fausse, quoi qu'il arrive. Donc (null==null) = false. Dans Ruby, (nil==nil) = true. Moments heureux.

Outre les autres bonnes réponses, j'aimerais parler de la cohérence entre les langues.

Lorsque nous pensons à une instruction if mathématiquement pure, nous comprenons que la condition peut être vraie ou fausse, pas d'autre valeur. Tous les principaux langages de programmation respectent cet idéal mathématique; Si vous donnez une valeur booléenne true / false à une instruction if, vous pouvez vous attendre à voir un comportement intuitif et cohérent tout le temps.

Jusqu'ici tout va bien. C'est ce que Java implémente, et seulement ce que Java implémente.

D'autres langues tentent d'apporter des commodités pour les valeurs non booléennes. Par exemple:

• Suppose nest un entier. Définissez maintenant if (n)le raccourci pour if (n != 0).
• Supposer xest un nombre à virgule flottante. Définissez maintenant if (x)le raccourci pour if (x != 0 && !isNaN(x)).
• Suppose pest un type de pointeur. Définissez maintenant if (p)le raccourci pour if (p != null).
• Suppose sest un type de chaîne. Maintenant, définir if (s)pour êtreif (s != null && s != "") .
• Suppose aest un type de tableau. Définissez maintenant if (a)pour être if (a != null && a.length > 0).

Cette idée de fournir des si-tests abrégés semble bonne en surface ... jusqu'à ce que vous rencontriez des différences de conceptions et d'opinions:

• if (0)est traité comme faux en C, Python, JavaScript; mais traité comme vrai dans Ruby.
• if ([]) est traité comme faux en Python mais vrai en JavaScript.

Chaque langue a ses propres bonnes raisons de traiter les expressions d’une manière ou d’une autre. (Par exemple, les seules valeurs de fausseté dans Ruby sont falseet nil, par conséquent, 0sont la vérité.)

Java a adopté une conception explicite pour vous obliger à fournir une valeur booléenne à une instruction if. Si vous avez rapidement traduit du code de C / Ruby / Python vers Java, vous ne pouvez pas laisser les tests if lax inchangés; vous devez écrire explicitement la condition en Java. Prendre un moment pour faire une pause et réfléchir peut vous éviter des erreurs négligentes.

Eh bien, chaque type scalaire en C, pointeur, booléen (depuis C99), nombre (virgule flottante ou non) et énumération (en raison de la correspondance directe avec des nombres) a une valeur de falsey "naturelle", ce qui est suffisant pour toute expression conditionnelle .

Java en a aussi (même si les pointeurs Java sont appelés des références et sont fortement restreints), mais il a introduit l'auto-boxing dans Java 5.0 qui brouille les eaux de façon inacceptable. En outre, les programmeurs Java exhortent la valeur intrinsèque de la saisie plus fréquente.

L'une erreur qui a donné naissance le débat se limitant des expressions conditionnelles au type booléen est la faute de frappe d'écrire une mission où une comparaison a été prévu, ce qui est pas adressée en limitant le type d'expressions conditionnelles du tout , mais en interdisant l' utilisation d'une nue cession d'expression pour sa valeur.

Tout compilateur moderne en C ou C ++ gère cela facilement, en donnant un avertissement ou une erreur pour de telles constructions douteuses si demandé.
Pour les cas où c'est exactement ce qui était prévu, l'ajout de parenthèses aide.

Pour résumer, restreindre à booléen (et son équivalent encadré en Java) ressemble à une tentative infructueuse de création d'une classe de fautes de frappe provoquée par le choix =d'affectation des erreurs de compilation.

Ma question n'est pas liée au style de codage incorrect. Je sais que c'est mauvais, mais je comprends pourquoi C ne le permet pas et java pas.

Les deux objectifs de conception de Java étaient:

1. Permettez au développeur de se concentrer sur le problème de l'entreprise. Rendez les choses plus simples et moins sujettes aux erreurs, par exemple la récupération de place afin que les développeurs n'aient pas à se concentrer sur les fuites de mémoire.

2. Portable entre les plates-formes, par exemple, exécuter sur n'importe quel ordinateur avec n'importe quel processeur.

L'utilisation de l'affectation en tant qu'expression était connue pour causer beaucoup de bugs dus aux fautes de frappe, donc sous l'objectif n ° 1 ci-dessus, il n'est pas autorisé de la façon dont vous essayez de l'utiliser.

De plus, déduire que toute valeur non nulle = vraie et toute valeur nulle = faux n'est pas nécessairement portable (oui, croyez-le ou non, certains systèmes traitent 0 comme vrai et 1 comme faux ), donc sous l'objectif n ° 2 ci-dessus, n'est pas autorisé implicitement . Vous pouvez toujours lancer explicitement bien sûr.

À titre d’exemple, c’est ce que font les autres langages: Swift requiert une expression d’un type prenant en charge le protocole "BooleanType", ce qui signifie qu’il doit avoir une méthode "boolValue". Le type "bool" supporte évidemment ce protocole et vous pouvez créer vos propres types le supportant. Les types entiers ne supportent pas ce protocole.

Dans les versions antérieures des langues, les types facultatifs étaient compatibles avec "BooleanType", vous pouviez donc écrire "if x" au lieu de "if x! = Nil". Ce qui rendait l'utilisation d'un "bool facultatif" très déroutant. Un booléen optionnel a les valeurs nil, false ou true et "if b" ne serait pas exécuté si b était nil et exécuté si b était true ou false. Ce n'est plus permis.

Et il semble y avoir un gars qui n'aime pas vraiment ouvrir vos horizons ...