NSInteger dovrebbe essere usato davvero ovunque?

Question

Ora c'è un iPhone in arrivo con architettura a 64 bit. long diventa 64 bit (mentre int rimane a 32 bit) e ovunque NSInteger è stato utilizzato è ora un long e quindi 64 bit non 32. E twitter ha un bel po 'di persone che dicono "Sono contento di aver usato NSInteger ovunque non int ".

Se è necessario memorizzare un valore che non superi i 32 bit (ad esempio in un ciclo che esegue il ciclo solo 25 volte), perché dovrebbe essere utilizzato a lungo, poiché i 32 (almeno) bit superiori stanno per essere vuoto

Se il programma ha funzionato su numeri interi a 32 bit, quale vantaggio offre l'utilizzo dei 64 bit per i numeri interi quando utilizza più memoria?

Inoltre ci saranno situazioni in cui l'uso di un numero intero a 64 bit dà un risultato diverso all'utilizzo di un numero intero a 32 bit. Quindi se usi NSInteger qualcosa può funzionare su un iPhone 5S ma non su un dispositivo precedente, mentre se int o long viene usato esplicitamente il risultato sarà lo stesso su qualsiasi dispositivo.

Answer 1

La memoria interna per NSInteger può essere uno dei molti tipi di supporto diversi, motivo per cui è possibile utilizzarlo ovunque e non è necessario preoccuparsene, il che è il punto centrale.

Answer 2

Se è necessario memorizzare un valore che non superi i 32 bit ... perché dovrebbe essere utilizzato a lungo?

Se si può davvero garantire tale garanzia, non vi è assolutamente alcun motivo per valutare un tipo a 64 bit su uno a 32 bit. Per operazioni semplici come loop limitati, contatori e aritmetica generale, gli interi a 32 bit sono sufficienti. Ma per operazioni più complesse, in particolare quelle necessarie per le applicazioni ad alte prestazioni, come quelle che eseguono l'elaborazione audio o delle immagini, l'aumento della quantità di dati che il processore può gestire in modalità a 64 bit è significativo.

Se il programma ha funzionato su numeri interi a 32 bit, allora quale vantaggio utilizza 64 bit per i numeri interi quando consuma più memoria?

L'uso di più memoria sembra una cosa negativa. Raddoppiando la dimensione di alcuni tipi di dati, possono essere indirizzati a più posti nella memoria e più memoria può essere indirizzata, minore è il tempo impiegato dal sistema operativo per caricare il codice. Inoltre, avendo il doppio della quantità di corsie per i dati in un bus del processore equivale a un ordine di grandezza di più valori che possono essere elaborati in un singolo go, e l'aumento delle dimensioni del registro significa un ordine di grandezza più dati possono essere mantenuti in giro in un registro Ciò equivale, in termini più semplici, a un raddoppio quasi automatico della velocità della maggior parte delle applicazioni.

Inoltre ci saranno situazioni in cui l'uso di un numero intero a 64 bit dà un risultato diverso all'utilizzo di un numero intero a 32 bit? ...

Sì, ma non nel modo in cui si penserebbe. I tipi di dati a 32 bit e le operazioni nonché le operazioni a 64 bit (la maggior parte simulata nel software, o hardware speciale o opcode in host a 32 bit) sono "relativamente stabili" in termini di dimensioni. Non è possibile ottenere quasi altrettante garanzie su un'architettura a 64 bit poiché diversi compilatori implementano versioni diverse dei tipi di dati a 64 bit (vedere LP64, SILP64, and LLP64). In pratica, questo significa che il casting di un tipo a 64 bit in un tipo a 32 bit, ad esempio un puntatore a un int, garantisce la perdita di informazioni, ma il casting tra due tipi di dati garantiti da 64 bit: un puntatore e un lungo su LP64 - è accettabile. ARM viene generalmente compilato usando LP64 (tutti gli interi sono a 32 bit, tutti i long sono 64 bit).Ancora una volta, la maggior parte degli sviluppatori non dovrebbe essere influenzata dallo switch, ma quando inizi a gestire numeri arbitrariamente grandi che cerchi di memorizzare in interi, la precisione diventa un problema.

Per questo motivo, consigliamo di utilizzare NSUInteger e NSInteger nelle interfacce pubbliche e API in cui non sono presenti controlli di controllo intrinseco o protezioni di overflow. Ad esempio, un TableView richiede una quantità di dati NSUInteger non perché è preoccupata per le strutture di dati a 32 e 64 bit, ma perché non può fornire alcuna garanzia sull'architettura su cui è compilata. Il tentativo di Apple di creare tipi di dati indipendenti dall'architettura è in realtà un po 'un lusso, considerando quanto poco lavoro devi fare per ottenere la compilazione del codice e "funziona solo" in entrambe le architetture.

Answer 3

Apple si prende cura della compatibilità con le versioni precedenti se l'app è in esecuzione su un motore a 32 o 64 bit e converte la variabile dietro le quinte in un tipo di dati appropriato utilizzando la macro __LP64__.

#if __LP64__ 
    typedef long NSInteger; 
    typedef unsigned long NSUInteger; 
#else 
    typedef int NSInteger; 
    typedef unsigned int NSUInteger; 
#endif