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

NSInteger/NSUInteger sont le Cacao défini remplacement régulier des types intégrés.

Est-il un avantage à l'utilisation de la NS* types sur les haut-ins? Lequel préférez-vous et pourquoi? Sont NSInteger et int la même largeur sur 32-bit /64-bit plates-formes?

InformationsquelleAutor Andrew Grant | 2008-08-17
  1. 57

    La façon dont je le comprends, c'est que NSInteger et coll. l'architecture sécuritaire versions de la C correspondant types. Leur taille varie en fonction de l'architecture, mais NSInteger, par exemple, c'est la garantie de tenir un pointeur valide pour l'architecture actuelle.

    Apple vous recommande d'utiliser ces pour fonctionner avec OS X 10.5 et versions ultérieures, et Pomme d'API:de la volonté de les utiliser, de sorte qu'il est certainement une bonne idée de prendre l'habitude de les utiliser. Ils nécessitent un peu plus de taper, mais en dehors de cela, il ne semble pas être une raison de ne pas les utiliser.

    • Ce n'est pas nécessairement le cas -- voir ma réponse "uantisation questions pour 64-bit runtime".
    InformationsquelleAutor Theo
  2. 43

    De quantification des questions pour 64-bit runtime

    Dans certaines situations, il peut y avoir une bonne raison d'utiliser les types standard au lieu de NSInteger: "inattendue" de la mémoire gonfler dans un système 64 bits.

    Clairement si un nombre entier est de 8 au lieu de 4 octets, la quantité de mémoire occupée par les valeurs est doublé. Étant donné que chaque valeur est un entier, cependant, vous devriez généralement pas s'attendre à l'empreinte mémoire de votre application afin de double. Cependant, la façon dont Mac OS X alloue de la mémoire, des changements en fonction de la quantité de mémoire requise.

    Actuellement, si vous demandez de 512 octets ou moins, malloc arrondi au prochain multiple de 16 octets. Si vous demandez plus de 512 octets, cependant, malloc arrondi au prochain multiple de 512 (au moins 1024 octets). Supposons ensuite que vous définissez une classe qui -- entre autres -- déclare cinq NSInteger les 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 serait, en théorie, exiger 544 octets. Mais, en raison de l'allocation de mémoire de la stratégie, chacun va effectivement occuper de 1024 octets (un quasi quadruplement). Si vous utilisez un grand nombre de ces objets, l'empreinte mémoire de votre application peut être considérablement plus élevée que celle que vous pourriez attendre. Si vous avez remplacé le NSInteger variables avec sint_32 variables, vous devez utiliser uniquement de 512 octets.

    Lorsque vous choisissez ce scalaire à utiliser, par conséquent, assurez-vous de choisir quelque chose de sensible. Est-il une raison pourquoi vous avez besoin d'une valeur de plus que vous avez besoin dans votre application 32 bits? À l'aide d'un entier de 64 bits pour compter un nombre de secondes est généralement pas nécessaire,...

    • Ouais, mais statistiquement, est plus productif de mettre les programmeurs mains hors de bits et d'octets. Nous parlons de Cacao, pas de la libc. Sur l'autre main sur l'iPhone, vous pouvez avoir un point, en fonction de l'application.
    • Il n'est pas clair ce que le problème est ici: Mes commentaires se rapportent directement à la de Cacao, et une considération importante lorsque vous choisissez le type de représenter une variable. Juste parce que vous êtes à l'aide de Cacao ne signifie pas que vous ne jamais avoir à tenir compte de facteurs liés à la performance de l'application...
    • Le fait que la mémoire est de plus en plus abondant sur les appareils modernes n'est pas une bonne excuse pour perdre la mémoire. Bien sûr, perdre un supplément de 32 bits ici ou il y a un petit changement, mais si c'est une structure de champ ou une variable d'instance, et il est affecté des milliers de fois, il devient un nickel et dime effet. Négligences de programmation, et sans le savoir, à l'aide de valeurs de 64 bits lors de la 32-bit entraîne la mémoire de la météorisation — si vous avez la possibilité de l'éviter, je ne peux pas penser à une bonne excuse pour ne pas prendre la faible fruits mûrs.
    InformationsquelleAutor mmalc
  3. 18

    64-bit est en fait la raison d'être de NSInteger et NSUInteger; avant 10.5, ceux qui n'existent pas. Les deux sont simplement définie comme la nostalgie en 64 bits, et que des entiers de 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, en utilisant en place de la base, types C quand vous voulez la "bit-native" de taille.

    CocoaDev a quelques infos.

    • Le lien n'est plus disponible.
    • Semble que le nouveau CocoaDev n'a pas que de l'article sur ce point.
    • Oui, il n'est pas.. & à l'avenir merci de ne pas poster des liens.. si possible poster la réponse ici. C'est contre stackoverflow la réponse de lignes directrices pour poster un lien seulement..
    InformationsquelleAutor Sören Kuklau
  4. 0

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

    InformationsquelleAutor JamesSugrue
  5. 0

    Pour l'importation et l'exportation de données vers des fichiers ou sur le net, j'ai utiliser UInt32, SInt64 etc...

    Ces sont garantis pour être d'une certaine taille, indépendamment de l'architecture et de l'aide au portage de code à d'autres plates-formes et des langages qui partagent également ces types de.

    InformationsquelleAutor Jason Fuerstenberg