¿Beneficios de usar NSInteger sobre int?

objective-c 64bit (4)

Estoy tratando de comprender cómo se ve afectado el desarrollo cuando se desarrolla para arquitecturas de 32 y 64 bits. Por lo que he investigado hasta ahora, entiendo que un int es siempre de 4 bytes, independientemente de la arquitectura del dispositivo que ejecuta la aplicación. Pero un NSInteger es de 4 bytes en un dispositivo de 32 bits y 8 bytes en un dispositivo de 64 bits. Me da la impresión de que NSInteger es "más seguro" y recomendado, pero no estoy seguro de cuál es el razonamiento para eso.

Mi pregunta es, si sabe que el posible valor que está utilizando nunca va a ser grande (tal vez lo esté usando para indexar en una matriz de 200 elementos o almacenar el recuento de objetos en una matriz), ¿por qué definirlo como un NSInteger ? Eso solo va a ocupar 8 bytes cuando no lo usará todo. ¿Es mejor definirlo como un int en esos casos? Si es así, ¿en qué caso desearía usar un NSInteger (en lugar de int o long etc.)? Obviamente, si necesita utilizar números más grandes, podría hacerlo con la arquitectura de 64 bits. Pero si lo necesitara para funcionar también en dispositivos de 32 bits, ¿no usaría long long porque también son 8 bytes en dispositivos de 32 bits? No veo por qué se usaría NSInteger , al menos al crear una aplicación que se ejecute en ambas arquitecturas.

Además, no puedo pensar en un método que tome o devuelva un tipo primitivo - int , y en su lugar utilice NSInteger , y me pregunto si hay más que solo el tamaño de los valores. Por ejemplo, (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section . Me gustaría entender por qué este es el caso. Suponiendo que es posible tener una tabla con 2.147.483.647 filas, ¿qué ocurriría en un dispositivo de 32 bits cuando se agrega una más - se ajusta a un -2,147,483,647? Y en un dispositivo de 64 bits sería 2.147.483.648. (¿Por qué devolver un valor firmado? Pensaría que debería estar sin firmar, ya que no puede tener un número negativo de filas).

En última instancia, me gustaría obtener una mejor comprensión del uso real de estos tipos de datos numéricos, ¡quizás algunos ejemplos de código sean excelentes!

Apple usa int porque para una variable de control de bucle (que solo se usa para controlar las iteraciones del bucle) el tipo de datos int está bien, tanto en el tamaño del tipo de datos como en los valores que puede contener para su bucle. No es necesario el tipo de datos dependiente de la plataforma aquí. Para una variable de control de bucle, incluso un int de 16 bits funcionará la mayor parte del tiempo.

Apple usa NSInteger para un valor de retorno de función o para un argumento de función porque en este caso el tipo de datos [tamaño] es importante, porque lo que está haciendo con una función es comunicar / pasar datos con otros programas o con otras piezas de código.

Apple usa NSInteger (o NSUInteger) cuando pasa un valor como argumento a una función o devuelve un valor desde una función.

Lo único para lo que usaría NSInteger es pasar valores ay desde una API que lo especifica. Aparte de eso, no tiene ninguna ventaja sobre un int o un largo. Al menos con un int o un largo sabes qué especificadores de formato usar en una declaración printf o similar.

Como continuación de la respuesta de Irfan: sizeof (NSInteger) es igual al tamaño de una palabra de procesador. Es mucho más simple y más rápido para el procesador operar con palabras

Personalmente creo que, 64 bits es en realidad el motivo de la existencia de NSInteger y NSUInteger; antes del 10.5, esos no existían. Los dos se definen simplemente como largos en 64 bits y como ints en 32 bits.

NSInteger / NSUInteger se definen como * typedef * dinámico para uno de estos tipos, y se definen así:

#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, usándolos en lugar de los tipos C más básicos cuando desee el tamaño ''bit-nativo''.

Le sugiero que lea detenidamente este enlace. CocoaDev tiene algo más de información.

Para el especificador de formato adecuado que debe usar para cada uno de estos tipos, consulte la sección Guía de programación de cadenas en Dependencias de plataforma

Recuerdo cuando asistía a la conferencia de desarrolladores de iOS. Hay que mirar el tipo de datos en iOS7. por ejemplo, utiliza NSInteger en un dispositivo de 64 bits y lo guarda en iCloud. luego desea sincronizar con un dispositivo inferior (digamos iPad 2da generación), su aplicación no se comportará igual, porque reconoce NSInteger en 4 bytes, no 8 bytes, entonces su cálculo sería incorrecto.

Pero hasta ahora, uso NSInteger porque la mayoría de mi aplicación no usa iCloud o no se sincroniza. y para evitar la advertencia del compilador.