Y a-t-il une différence entre OUI / NON, VRAI / FAUX et Vrai / Faux dans objective-c?

Question simple vraiment; y a-t-il une différence entre ces valeurs (et y a-t-il une différence entre BOOL et bool)? Un collègue a mentionné qu'ils évaluaient à différentes choses dans Objective-C, mais quand j'ai regardé les typedefs dans leurs fichiers .h respectifs, YES / TRUE / true étaient tous définis comme 1et NO / FALSE / false étaient tous définis comme 0. Y a-t-il vraiment une différence?

Il n'y a aucune différence pratique à condition d'utiliser des BOOLvariables comme booléens. C traite les expressions booléennes selon qu'elles évaluent à 0 ou non à 0. Donc:

if(someVar ) { ... }
if(!someVar) { ... }

signifie la même chose que

if(someVar!=0) { ... }
if(someVar==0) { ... }

c'est pourquoi vous pouvez évaluer n'importe quel type ou expression primitive comme un test booléen (y compris, par exemple, des pointeurs). Notez que vous devriez faire le premier, pas le second.

Notez qu'il y a une différence si vous attribuez des valeurs à un obtus que l' on appelle BOOLvariable et test pour des valeurs spécifiques, donc toujours les utiliser comme booléens et seulement les affecter de leurs #definevaleurs.

Surtout, ne testez jamais les booléens en utilisant une comparaison de caractères - ce n'est pas seulement risqué car on someVarpourrait attribuer une valeur non nulle qui n'est pas OUI, mais, à mon avis plus important encore, cela ne parvient pas à exprimer correctement l'intention:

if(someVar==YES) { ... } // don't do this!
if(someVar==NO ) { ... } // don't do this either!

En d'autres termes, utilisez des constructions telles qu'elles sont prévues et documentées pour être utilisées et vous vous épargnerez un monde de blessures en C.

Je crois qu'il y a une différence entre boolet BOOL, consultez cette page Web pour une explication de pourquoi:
http://iosdevelopertips.com/objective-c/of-bool-and-yes.html

Comme il BOOLs'agit d'un type unsigned charplutôt que primitif, les variables de type BOOLpeuvent contenir des valeurs autres que YESet NO.

Considérez ce code:

BOOL b = 42;

if (b) {
    printf("b is not NO!\n");
}

if (b != YES) {
    printf("b is not YES!\n");
}

La sortie est:

b n'est pas NON!
b n'est pas OUI!

Pour la plupart des gens, c'est une préoccupation inutile, mais si vous voulez vraiment un booléen, il est préférable d'utiliser un bool. Je devrais ajouter: le SDK iOS utilise généralement BOOLsur ses définitions d'interface, c'est donc un argument avec lequel s'en tenir BOOL.

J'ai fait un test exhaustif à ce sujet. Mes résultats devraient parler d'eux-mêmes:

//These will all print "1"
NSLog(@"%d", true == true);
NSLog(@"%d", TRUE == true);
NSLog(@"%d", YES  == true);
NSLog(@"%d", true == TRUE);
NSLog(@"%d", TRUE == TRUE);
NSLog(@"%d", YES  == TRUE);
NSLog(@"%d", true == YES);
NSLog(@"%d", TRUE == YES);
NSLog(@"%d", YES  == YES);

NSLog(@"%d", false == false);
NSLog(@"%d", FALSE == false);
NSLog(@"%d", NO    == false);
NSLog(@"%d", false == FALSE);
NSLog(@"%d", FALSE == FALSE);
NSLog(@"%d", NO    == FALSE);
NSLog(@"%d", false == NO);
NSLog(@"%d", FALSE == NO);
NSLog(@"%d", NO    == NO);


//These will all print "0"
NSLog(@"%d", false == true);
NSLog(@"%d", FALSE == true);
NSLog(@"%d", NO    == true);
NSLog(@"%d", false == TRUE);
NSLog(@"%d", FALSE == TRUE);
NSLog(@"%d", NO    == TRUE);
NSLog(@"%d", false == YES);
NSLog(@"%d", FALSE == YES);
NSLog(@"%d", NO    == YES);

NSLog(@"%d", true == false);
NSLog(@"%d", TRUE == false);
NSLog(@"%d", YES  == false);
NSLog(@"%d", true == FALSE);
NSLog(@"%d", TRUE == FALSE);
NSLog(@"%d", YES  == FALSE);
NSLog(@"%d", true == NO);
NSLog(@"%d", TRUE == NO);
NSLog(@"%d", YES  == NO);

La sortie est:

2013-02-19 20:30:37.061 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.061 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.072 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.073 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.073 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.074 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.074 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.075 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.075 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.076 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.077 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.077 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.078 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.078 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.079 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.079 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.080 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.080 BooleanTests[27433:a0f] 1
2013-02-19 20:30:37.081 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.081 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.082 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.091 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.092 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.093 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.093 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.094 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.094 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.095 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.095 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.096 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.096 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.097 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.098 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.101 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.102 BooleanTests[27433:a0f] 0
2013-02-19 20:30:37.102 BooleanTests[27433:a0f] 0

Vous voudrez peut-être lire les réponses à cette question . En résumé, en Objective-C (d'après la définition en objc.h):

typedef signed char        BOOL; 
// BOOL is explicitly signed so @encode(BOOL) == "c" rather than "C" 
// even if -funsigned-char is used.
#define OBJC_BOOL_DEFINED


#define YES             (BOOL)1
#define NO              (BOOL)0

La principale différence (dangereuse!) Entre trueet YESréside dans la sérialisation JSON.

Par exemple, nous avons une requête de serveur de type JSON et devons envoyer true / false dans json sens:

NSDictionary *r1 = @{@"bool" : @(true)};
NSDictionary *r2 = @{@"bool" : @(YES)};
NSDictionary *r3 = @{@"bool" : @((BOOL)true)};

Ensuite, nous le convertissons en chaîne JSON avant de l'envoyer en tant que

NSData *data = [NSJSONSerialization  dataWithJSONObject:requestParams options:0 error:nil];
NSString *jsonString = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];

Le résultat est

jsonString1 // {"bool":1}
jsonString2 // {"bool":true}
jsonString3 // {"bool":true}

En raison de la logique de l'API, jsonString1une erreur peut survenir.

Soyez donc prudent avec les booléens en Objective-C.

Pour résumer, seules les @YESvaleurs exactes et castées @((BOOL)expression)sont de __NSCFBooleantype et converties en truesérialisation JSON. Toutes les autres expressions comme @(expression1 && expression2)(paire @(YES && YES)) sont de __NSCFNumber (int)type et converties 1en JSON.

PS Vous pouvez simplement utiliser un booléen à valeur chaîne

@{@"bool" : @"true"}; // in JSON {"bool":true}

Il y a un bug subtil que personne n'a mentionné ici, que je pensais inclure ... plus une erreur logique qu'autre chose:

int i = 2;
if(i);        //true
if(i==YES);   // false
if((!!i)==YES); //true

donc le problème ici est juste cela (YES==1)et en C la comparaison n'est pas booléenne, mais basée sur la valeur.

parce que YESc'est juste un #define(plutôt que quelque chose d'intrinsèque à la langue), il doit avoir une certaine valeur, et 1cela a le plus de sens.

Je pense qu'ils ajoutent OUI / NON pour être plus explicites dans de nombreux cas. Par exemple:

[button setHidden:YES];

sonne mieux que

[button setHidden:TRUE];

Examinons d'abord ce qu'est le vrai et le faux et ce qui leur donne un sens en premier lieu.

nous pouvons construire une structure appelée if a then b else c dans le calcul lambda comme suit:

(\ifThenElse. <use if then else>)(\a. \b. \c. a b c)

En JavaScript, cela ressemble à ceci:

(function(ifThenElse) {
    // use ifThenElse
})(function(a) {
    return function(b) {
        return function(c) {
            return a(b)(c);
        };
    };
});

pour que ifThenElse soit utile, nous avons besoin d'une fonction "true" qui choisit soit la droite soit la gauche, et le fait en ignorant l'autre option, ou une fonction "false" qui choisit l'option "true" ne prend pas.

Nous pouvons définir ces fonctions comme suit:

(\true. <use true>)(\a. \b. a) and (\false. <use false>)(\a. \b. b)

en JavaScript, cela ressemble à ceci:

(function(True) {
    // use True
})(function(a) {
     return function(b) {
         return a;
     }
});

(function(False) {
    // use True
})(function(a) {
     return function(b) {
         return b;
     }
});

maintenant nous pouvons faire ce qui suit

(\true. \false. \ifThenElse. \doThis. \doThat. ifThenElse true doThis doThat)
(\a. \b. a)(\a. \b. b)(\a. \b. \c. a b c)(\a. ())(\a. ())

avec doThis et doThat étant (\ a. ()) parce que le calcul lambda n'offre aucun service tel que l'impression / maths / chaînes, tout ce que nous pouvons faire est de ne rien faire et dire que nous l'avons fait (et plus tard tricher en le remplaçant par des services dans notre système qui fournit les effets secondaires que nous voulons)

alors voyons cela en action.

(function(True) {
    return (function(False) {
        return (function(ifThenElse) {
            return (function(doThis) {
                return (function(doThat) {
                    return ifThenElse(True)(doThis)(doThat);
                });
            });
        });
    })
})(function(a) {
     return function(b) {
         return a;
     }
})(function(a) {
     return function(b) {
         return b;
     }
})(function(a) {
    return function(b) {
        return function(c) {
            return a(b)(c);
        };
    };
})(function(a) { console.log("you chose LEFT!"); })
(function(a) {console.log("you chose RIGHT");})();

C'est un environnement profond qui pourrait être simplifié si nous étions autorisés à utiliser des tableaux / cartes / arguments / ou plus d'une instruction pour diviser en plusieurs fonctions, mais je veux garder c'est aussi pur que je peux me limiter aux fonctions d'exactement un argument seulement.

notez que le nom True / False n'a aucune signification inhérente, nous pouvons facilement les renommer en oui / non, gauche / droite, droite / gauche, zéro / un, pomme / orange. Cela a une signification en ce que quel que soit le choix qui est fait, il n'est causé que par le type de choix qui l'a fait. Donc, si "LEFT" est imprimé, nous savons que le sélecteur ne peut être que vrai, et sur la base de cette connaissance, nous pouvons guider nos décisions ultérieures.

Donc pour résumer

function ChooseRight(left) {
    return function _ChooseRight_inner(right) {
        return right;
    }
}
function ChooseLeft(left) {
    return function _ChooseLeft_inner(right) {
        return left;
    }
}

var env = {
    '0': ChooseLeft,
    '1': ChooseRight,
    'false': ChooseRight,
    'true': ChooseLeft,
    'no': ChooseRight
    'yes': ChooseLeft,
    'snd': ChooseRight,
    'fst': ChooseLeft
};
var _0 = env['0'];
var _1 = env['1'];
var _true = env['true'];
var _false = env['false'];
var yes = env['yes'];
var no = env['no'];

// encodes church zero or one to boolean
function lambda_encodeBoolean(self) {
    return self(false)(true);
}
// decodes a Boolean to church zero or one
function lambda_decodeBoolean(self) {
    console.log(self, self ? env['true'] : env['false']);
    return self ? env['true'] : env['false'];
}

lambda_decodeBoolean('one' === 'two')(function() {
    console.log('one is two');
})(function() {
    console.log('one is not two');
})();

lambda_decodeBoolean('one' === 'one')(function() {
    console.log('one is one');
})(function() {
    console.log('one is not one');
})();

Non, OUI / NON est une manière différente de se référer à TRUE / FALSE (1/0)