Objectif-C: BOOL vs bool

J'ai vu le "nouveau type" BOOL( YES, NO).

J'ai lu que ce type est presque comme un caractère.

Pour les tests, j'ai fait:

NSLog(@"Size of BOOL %d", sizeof(BOOL));
NSLog(@"Size of bool %d", sizeof(bool));

C'est bien de voir que les deux journaux affichent "1" (parfois en C ++, bool est un entier et sa taille est 4)

Je me demandais donc s'il y avait des problèmes avec le type booléen ou quelque chose du genre?

Puis-je simplement utiliser bool (qui semble fonctionner) sans perdre de vitesse?

D'après la définition dans objc.h:

#if (TARGET_OS_IPHONE && __LP64__)  ||  TARGET_OS_WATCH
typedef bool BOOL;
#else
typedef signed char BOOL; 
// BOOL is explicitly signed so @encode(BOOL) == "c" rather than "C" 
// even if -funsigned-char is used.
#endif

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

Donc, oui, vous pouvez supposer que BOOL est un caractère. Vous pouvez utiliser le type (C99) bool, mais tous les frameworks Objective-C d'Apple et la plupart des codes Objective-C / Cocoa utilisent BOOL, vous vous éviterez donc des maux de tête si le typedef change en utilisant simplement BOOL.

Comme mentionné ci-dessus, BOOL est un caractère signé. bool - type de la norme C99 (int).

BOOL - OUI / NON. booléen - vrai / faux.

Voir des exemples:

bool b1 = 2;
if (b1) printf("REAL b1 \n");
if (b1 != true) printf("NOT REAL b1 \n");

BOOL b2 = 2;
if (b2) printf("REAL b2 \n");
if (b2 != YES) printf("NOT REAL b2 \n");

Et le résultat est

RÉEL b1
RÉEL b2
PAS RÉEL b2

Notez que bool! = BOOL. Le résultat ci-dessous n'est encore qu'une fois - REAL b2

b2 = b1;
if (b2) printf("ONCE AGAIN - REAL b2 \n");
if (b2 != true) printf("ONCE AGAIN - NOT REAL b2 \n");

Si vous voulez convertir bool en BOOL, vous devez utiliser le code suivant

BOOL b22 = b1 ? YES : NO; //and back - bool b11 = b2 ? true : false;

Donc, dans notre cas:

BOOL b22 = b1 ? 2 : NO;
if (b22)    printf("ONCE AGAIN MORE - REAL b22 \n");
if (b22 != YES) printf("ONCE AGAIN MORE- NOT REAL b22 \n");

Et donc ... ce que nous obtenons maintenant? :-)

Au moment de la rédaction de cet article, il s'agit de la version la plus récente de objc.h:

/// Type to represent a boolean value.
#if (TARGET_OS_IPHONE && __LP64__)  ||  TARGET_OS_WATCH
#define OBJC_BOOL_IS_BOOL 1
typedef bool BOOL;
#else
#define OBJC_BOOL_IS_CHAR 1
typedef signed char BOOL; 
// BOOL is explicitly signed so @encode(BOOL) == "c" rather than "C" 
// even if -funsigned-char is used.
#endif

Cela signifie que sur les appareils iOS 64 bits et WatchOS, BOOLc'est exactement la même chose boolque sur tous les autres appareils (OS X, iOS 32 bits), il est signed charet ne peut même pas être remplacé par l'indicateur du compilateur-funsigned-char

Cela signifie également que cet exemple de code fonctionnera différemment sur différentes plates-formes (je l'ai testé moi-même):

int myValue = 256;
BOOL myBool = myValue;
if (myBool) {
    printf("i'm 64-bit iOS");
} else {
    printf("i'm 32-bit iOS");
}

BTW choses ne Assigner aiment array.countà BOOLvariables car environ 0,4% des valeurs possibles sera négatif.

Le type Objective-C que vous devez utiliser est BOOL. Il n'y a rien de tel qu'un type de données booléen natif, donc pour être sûr que le code compile sur tous les compilateurs utilisent BOOL. (Il est défini dans Apple-Frameworks.

Oui, BOOL est un typedef pour un caractère signé selon objc.h.

Je ne sais pas pour bool, cependant. C'est un truc C ++, non? S'il est défini comme un caractère signé où 1 est OUI / vrai et 0 est NON / faux, alors j'imagine que celui que vous utilisez n'a pas d'importance.

Puisque BOOL fait partie d'Objective-C, cependant, il est probablement plus logique d'utiliser un BOOL pour plus de clarté (d'autres développeurs d'Objective-C pourraient être perplexes s'ils voient un bool en cours d'utilisation).

Une autre différence entre bool et BOOL est qu'ils ne se convertissent pas exactement dans le même type d'objets, lorsque vous effectuez une observation clé-valeur ou lorsque vous utilisez des méthodes telles que - [NSObject valueForKey:].

Comme tout le monde l'a dit ici, BOOL est char. En tant que tel, il est converti en NSNumber contenant un char. Cet objet est indiscernable d'un NSNumber créé à partir d'un caractère normal comme «A» ou «\ 0». Vous avez totalement perdu l'information que vous aviez à l'origine un BOOL.

Cependant, bool est converti en CFBoolean, qui se comporte de la même manière que NSNumber, mais qui conserve l'origine booléenne de l'objet.

Je ne pense pas que ce soit un argument dans un débat BOOL vs bool, mais cela peut vous mordre un jour.

De manière générale, vous devriez aller avec BOOL, car c'est le type utilisé partout dans les API Cocoa / iOS (conçu avant C99 et son type booléen natif).

La réponse acceptée a été modifiée et son explication est devenue un peu incorrecte. L'échantillon de code a été actualisé, mais le texte ci-dessous reste le même. Vous ne pouvez pas supposer que BOOL est un caractère pour le moment car il dépend de l'architecture et de la plate-forme. Ainsi, si vous exécutez votre code sur une plate-forme 32 bits (par exemple iPhone 5) et imprimez @encode (BOOL), vous verrez "c". Cela correspond à un type char . Mais si vous exécutez votre code sur l'iPhone 5s (64 bits), vous verrez "B". Cela correspond à un type booléen .

Je vais contre la convention ici. Je n'aime pas les typedef aux types de base. Je pense que c'est une indirection inutile qui enlève de la valeur.

1. Quand je verrai le type de base dans votre source, je le comprendrai instantanément. Si c'est un typedef, je dois le chercher pour voir à quoi je m'occupe vraiment.
2. Lors du portage vers un autre compilateur ou de l'ajout d'une autre bibliothèque, leur ensemble de typedefs peut entrer en conflit et provoquer des problèmes difficiles à déboguer. Je viens juste de m'en occuper en fait. Dans une bibliothèque, boolean a été typé en entier, et dans mingw / gcc, il est typé en caractère.

Comme mentionné ci-dessus, il BOOLpeut s'agir d'un unsigned chartype en fonction de votre architecture, alors qu'il boolest de type int. Une expérience simple montrera la différence pourquoi BOOL et bool peuvent se comporter différemment:

bool ansicBool = 64;
if(ansicBool != true) printf("This will not print\n");

printf("Any given vlaue other than 0 to ansicBool is evaluated to %i\n", ansicBool);

BOOL objcBOOL = 64;
if(objcBOOL != YES) printf("This might print depnding on your architecture\n");

printf("BOOL will keep whatever value you assign it: %i\n", objcBOOL);

if(!objcBOOL) printf("This will not print\n");

printf("! operator will zero objcBOOL %i\n", !objcBOOL);

if(!!objcBOOL) printf("!! will evaluate objcBOOL value to %i\n", !!objcBOOL);

À votre grande surprise if(objcBOOL != YES), le compilateur évaluera à 1, car il YESs'agit en fait du code de caractère 1, et aux yeux du compilateur, le code de caractère 64 n'est bien sûr pas égal au code de caractère 1, donc l'instruction if sera évaluée àYES/true/1 et la ligne suivante sera courir. Cependant, comme un booltype aucun zéro évalue toujours la valeur entière de 1, le problème ci-dessus n'affectera pas votre code. Voici quelques bons conseils si vous souhaitez utiliser le Objective-C BOOLtype par rapport au ANSI C booltype:

• Attribuez toujours le YESouNO valeur et rien d'autre.
• Convertir BOOL types en utilisant double not!! opérateur pour éviter des résultats inattendus.
• Lors de la vérification de l' YESutilisation, if(!myBool) instead of if(myBool != YES)il est beaucoup plus propre d'utiliser l' !opérateur not et donne le résultat attendu.

Soyez également conscient des différences de diffusion, en particulier lorsque vous travaillez avec des masques de bits, en raison de la diffusion en caractère signé:

bool a = 0x0100;
a == true;  // expression true

BOOL b = 0x0100;
b == false; // expression true on !((TARGET_OS_IPHONE && __LP64__) || TARGET_OS_WATCH), e.g. MacOS
b == true;  // expression true on (TARGET_OS_IPHONE && __LP64__) || TARGET_OS_WATCH

Si BOOL est un caractère signé au lieu d'un booléen, la conversion de 0x0100 en BOOL supprime simplement le bit défini et la valeur résultante est 0.