Dans Cocoa, préférez-vous NSInteger ou int, et pourquoi ?

Question

NSInteger/NSUInteger sont des remplacements définis par Cocoa pour les types intégrés réguliers.

Y a-t-il un avantage à utiliser les types NS* par rapport aux types intégrés ?Lequel tu préfères, et pourquoi?Sont NSInteger et int la même largeur sur les plateformes 32 bits/64 bits ?

Answer 1

D'après ce que je comprends, NSInteger et al.sont des versions architecturales sécurisées des types C correspondants.Fondamentalement, leur taille varie en fonction de l'architecture, mais NSInteger, par exemple, est assuré de contenir tout pointeur valide pour l'architecture actuelle.

Apple vous recommande de les utiliser pour travailler avec OS X 10.5 et versions ultérieures, et les API d'Apple les utiliseront, c'est donc certainement une bonne idée de prendre l'habitude de les utiliser.Ils nécessitent un peu plus de saisie, mais à part cela, cela ne semble pas être une raison pour ne pas les utiliser.

Answer 2

Problèmes de quantification pour l'exécution 64 bits

Dans certaines situations, il peut y avoir de bonnes raisons d'utiliser des types standard au lieu de NSInteger:gonflement de la mémoire "inattendu" dans un système 64 bits.

Clairement, si un entier vaut 8 au lieu de 4 octets, la quantité de mémoire occupée par les valeurs est doublée.Étant donné que toutes les valeurs ne sont pas des nombres entiers, vous ne devez généralement pas vous attendre à ce que l'empreinte mémoire de votre application double.Cependant, la manière dont Mac OS X alloue la mémoire change en fonction de la quantité de mémoire demandée.

Actuellement, si vous demandez 512 octets ou moins, malloc arrondit au multiple suivant de 16 octets.Cependant, si vous demandez plus de 512 octets, malloc arrondit au multiple suivant de 512 (au moins 1024 octets).Supposons alors que vous définissiez une classe qui -- entre autres -- déclare cinq NSInteger variables d'instance, et que sur un système 32 bits, chaque instance occupe, disons, 272 octets.Sur un système 64 bits, les instances nécessiteraient en théorie 544 octets.Mais, en raison de la stratégie d’allocation de mémoire, chacun occupera en réalité 1 024 octets (soit presque quatre fois plus).Si vous utilisez un grand nombre de ces objets, l'empreinte mémoire de votre application peut être considérablement plus importante que ce à quoi vous pourriez vous attendre.Si vous avez remplacé le NSInteger variable avec sint_32 variables, vous n’utiliseriez que 512 octets.

Lorsque vous choisissez le scalaire à utiliser, assurez-vous donc de choisir quelque chose de sensé.Y a-t-il une raison pour laquelle vous avez besoin d'une valeur supérieure à celle dont vous avez besoin dans votre application 32 bits ?Il est peu probable que l'utilisation d'un entier de 64 bits pour compter un nombre de secondes soit nécessaire...

Answer 3

64 bits est en fait la raison d'être de NSInteger et NSUInteger ;avant 10.5, ceux-ci n’existaient pas.Les deux sont simplement définis comme des longs en 64 bits et comme des entiers en 32 bits :

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

Ainsi, utilisez-les à la place des types C plus basiques lorsque vous souhaitez la taille « bit native ».

CocoaDev a quelques informations supplémentaires.

Answer 4

Je préfère les déclarations standard de style C, mais uniquement parce que je bascule entre plusieurs langues et que je n'ai pas à trop y penser, mais on dirait que je devrais commencer à regarder nsinteger

Answer 5

Pour importer et exporter des données vers des fichiers ou sur le net, j'utilise UInt32, SInt64 etc...

Ceux-ci sont garantis d'avoir une certaine taille quelle que soit l'architecture et aident au portage du code vers d'autres plates-formes et langages qui partagent également ces types.