Obiettivo-C: BOOL vs bool

Ho visto il "nuovo tipo" BOOL( YES, NO).

Ho letto che questo tipo è quasi come un personaggio.

Per i test ho fatto:

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

È bello vedere che entrambi i registri visualizzano "1" (a volte in C ++ bool è un int e la sua dimensione è 4)

Quindi mi stavo solo chiedendo se ci fossero dei problemi con il tipo di bool o qualcosa del genere?

Posso semplicemente usare Bool (che sembra funzionare) senza perdere velocità?

Dalla definizione in 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)

Quindi, sì, puoi presumere che BOOL sia un personaggio. Puoi usare il tipo (C99) bool, ma tutti i framework Objective-C di Apple e la maggior parte del codice Objective-C / Cocoa usano BOOL, così ti risparmierai mal di testa se il typedef cambia mai usando semplicemente BOOL.

Come accennato in precedenza, BOOL è un carattere firmato. bool - tipo dallo standard C99 (int).

BOOL - SÌ / NO. bool: vero / falso.

Vedi esempi:

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");

E il risultato è

REAL b1
REAL b2
NON REAL b2

Nota che bool! = BOOL. Il risultato sotto è DI NUOVO UNA VOLTA - REAL b2

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

Se vuoi convertire bool in BOOL devi usare il codice successivo

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

Quindi, nel nostro caso:

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");

E quindi .. cosa otteniamo ora? :-)

Al momento in cui scrivo questa è la versione più recente di 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

Significa che sui dispositivi iOS a 64 bit e su WatchOS BOOLè esattamente la stessa cosa che boolsu tutti gli altri dispositivi (OS X, iOS a 32 bit) signed chare non può nemmeno essere sovrascritto dal flag del compilatore-funsigned-char

Significa anche che questo codice di esempio verrà eseguito in modo diverso su piattaforme diverse (testato io stesso):

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

BTW non assegna mai cose come array.counta BOOLvariabili perché circa lo 0,4% dei possibili valori sarà negativo.

Il tipo Objective-C che dovresti usare è BOOL. Non c'è niente come un tipo di dati booleano nativo, quindi per essere sicuri che il codice venga compilato su tutti i compilatori BOOL. (È definito in Apple-Frameworks.

Sì, BOOL è un typedef per un carattere firmato secondo objc.h.

Non so di bool, però. Questa è una cosa C ++, giusto? Se è definito come un carattere con segno in cui 1 è SÌ / vero e 0 è NO / falso, allora immagino che non importa quale usi.

Poiché BOOL fa parte di Objective-C, tuttavia, probabilmente ha più senso utilizzare un BOOL per chiarezza (altri sviluppatori di Objective-C potrebbero essere perplessi se vedono un bool in uso).

Un'altra differenza tra bool e BOOL è che non si convertono esattamente nello stesso tipo di oggetti, quando si fa l'osservazione del valore-chiave o quando si usano metodi come - [NSObject valueForKey:].

Come tutti hanno detto qui, BOOL è char. Come tale, viene convertito in un NSNumber che contiene un carattere. Questo oggetto non è distinguibile da un NSNumber creato da un carattere normale come 'A' o '\ 0'. Hai completamente perso le informazioni che originariamente avevi un BOOL.

Tuttavia, bool viene convertito in un CFBoolean, che si comporta come NSNumber, ma che conserva l'origine booleana dell'oggetto.

Non penso che questo sia un argomento in un dibattito BOOL vs. bool, ma un giorno potrebbe morderti.

In generale, dovresti andare con BOOL, poiché questo è il tipo usato ovunque nelle API Cocoa / iOS (progettato prima di C99 e del suo tipo bool nativo).

La risposta accettata è stata modificata e la sua spiegazione diventa un po 'errata. L'esempio di codice è stato aggiornato, ma il testo seguente rimane lo stesso. Non puoi supporre che BOOL sia un char per ora poiché dipende dall'architettura e dalla piattaforma. Pertanto, se esegui il codice su piattaforma a 32 bit (ad esempio iPhone 5) e stampa @encode (BOOL) vedrai "c". Corrisponde a un tipo di carattere . Ma se esegui il tuo codice su iPhone 5s (64 bit) vedrai "B". Corrisponde a un tipo di bool .

Vado contro le convenzioni qui. Non mi piacciono i typedef ai tipi base. Penso che sia un inutile riferimento indiretto che rimuove il valore.

1. Quando vedo il tipo di base nella tua fonte lo capirò immediatamente. Se è un errore di battitura, devo cercarlo per vedere con cosa ho davvero a che fare.
2. Quando si esegue il porting su un altro compilatore o si aggiunge un'altra libreria, la loro serie di typedef potrebbe essere in conflitto e causare problemi difficili da eseguire il debug. In effetti, ho appena finito di occuparmene. In una libreria booleano è stato digitato in int, e in mingw / gcc è tipizzato in un carattere.

Come accennato in precedenza BOOLpotrebbe essere un unsigned chartipo a seconda della tua architettura, mentre boolè di tipo int. Un semplice esperimento mostrerà la differenza perché BOOL e bool possono comportarsi diversamente:

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);

Con tua sorpresa if(objcBOOL != YES)valuterà 1 dal compilatore, poiché in YESrealtà è il codice carattere 1, e agli occhi del compilatore, il codice carattere 64 non è ovviamente uguale al codice carattere 1, quindi l'istruzione if verrà valutata YES/true/1e la riga seguente sarà correre. Tuttavia, poiché un booltipo nessuno zero restituisce sempre il valore intero 1, il problema sopra riportato non avrà effetto sul codice. Di seguito sono riportati alcuni suggerimenti utili se si desidera utilizzare il Objective-C BOOLtipo rispetto al ANSI C booltipo:

• Assegna sempre il valore YESo NOe nient'altro.
• Converti i BOOLtipi usando double not !!operator per evitare risultati imprevisti.
• Quando si controlla l' YESuso if(!myBool) instead of if(myBool != YES), è molto più pulito utilizzare l' !operatore non e si ottiene il risultato previsto.

Inoltre, fai attenzione alle differenze nel casting, specialmente quando lavori con maschere di bit, a causa del casting con caratteri firmati:

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

Se BOOL è un carattere con segno anziché un valore booleano, il cast di 0x0100 su BOOL rilascia semplicemente il bit impostato e il valore risultante è 0.