objective c - plataforma - En Cocoa, ¿prefieres NSInteger o int, y por qué?
versiones de objective c (5)
NSInteger / NSUInteger son reemplazos definidos por Cocoa para los tipos incorporados regulares.
¿Hay algún beneficio al usar los tipos NS * sobre los integrados? cuál prefieres y por qué? ¿Están NSInteger e int el mismo ancho en plataformas de 32 bits / 64 bits?
Problemas de cuantificación para el tiempo de ejecución de 64 bits
En algunas situaciones, puede haber una buena razón para usar tipos estándar en lugar de NSInteger : la NSInteger memoria "inesperada" en un sistema de 64 bits.
Claramente, si un número entero es 8 en lugar de 4 bytes, la cantidad de memoria tomada por valores se duplica. Sin embargo, dado que no todos los valores son enteros, normalmente no debería esperarse que la huella de memoria de su aplicación se duplique. Sin embargo, la forma en que Mac OS X asigna la memoria cambia en función de la cantidad de memoria solicitada.
Actualmente, si solicita 512 bytes o menos, malloc redondea al siguiente múltiplo de 16 bytes. Sin embargo, si solicita más de 512 bytes, malloc redondea al siguiente múltiplo de 512 (al menos 1024 bytes). Supongamos entonces que define una clase que, entre otros, declara cinco variables de instancia NSInteger , y que en un sistema de 32 bits cada instancia ocupa, digamos, 272 bytes. En un sistema de 64 bits, las instancias en teoría requerirían 544 bytes. Pero, debido a la estrategia de asignación de memoria, cada uno realmente ocupará 1024 bytes (un aumento de casi cuatro veces). Si usa una gran cantidad de estos objetos, la huella de memoria de su aplicación puede ser considerablemente mayor de lo que podría esperar. Si reemplazó las variables de NSInteger con variables sint_32 , solo usaría 512 bytes.
Cuando elige qué escalar utilizar, asegúrese de elegir algo sensato. ¿Hay alguna razón por la que necesita un valor mayor de lo que necesitaba en su aplicación de 32 bits? No es probable que sea necesario usar un número entero de 64 bits para contar un número de segundos ...
64 bits es en realidad la razón de ser de NSInteger y NSUInteger; antes de 10.5, esos no existían. Los dos simplemente se definen como longs en 64 bits y como ints 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
Por lo tanto, utilícelos en lugar de los tipos C más básicos cuando desee el tamaño "bit-native".
La forma en que lo entiendo es que NSInteger et al. son versiones de arquitectura segura de los tipos de C correspondientes. Básicamente, su tamaño varía según la arquitectura, pero NSInteger, por ejemplo, garantiza que contiene cualquier puntero válido para la arquitectura actual.
Apple recomienda que los uses para trabajar con OS X 10.5 en adelante, y los API de Apple los usarán, por lo que definitivamente es una buena idea adquirir el hábito de usarlos. Requieren un poco más de tipeo, pero aparte de eso, no parece ser ninguna razón para no usarlos.
Para importar y exportar datos a archivos o a través de la red, uso UInt32 , SInt64 , etc.
Se garantiza que tienen un cierto tamaño independientemente de la arquitectura y ayudan a transferir el código a otras plataformas y lenguajes que también comparten esos tipos.
Prefiero las declaraciones de estilo c estándar, pero solo porque cambio de varios idiomas y no tengo que pensar demasiado sobre eso, pero parece que debería empezar a buscar nsinteger