uso de NSString estático frente a constantes NSString en línea

Question

En Objective-C, entiendo que la directiva @ "foo" define una constante NSString. Si utilizo @ "foo" en varios lugares, se hace referencia al mismo objeto NSString inmutable.

¿Por qué aparece este fragmento de código en cuando (por ejemplo, en UITableViewCell reutilización):

static NSString *CellId = @"CellId"; 
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellId]; 
if (cell == nil) { 
    cell = [[UITableViewCell alloc] initWithStyle:style reuseIdentifier:CellId]; 

En lugar de simplemente:

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"CellId"]; 
if (cell == nil) { 
    cell = [[UITableViewCell alloc] initWithStyle:style reuseIdentifier:@"CellId"]; 

supongo que es para protegerme de hacer un error tipográfico en el nombre del identificador que el compilador no captaría. Pero si es así, ¿no acabo:

#define kCellId @"CellId" 

y evitar la NSString * poco estática? ¿O me estoy perdiendo algo?

Answer 1

es una buena práctica para encender literales en constantes debido a que:

1. Ayuda a evitar errores tipográficos, como usted ha dicho
2. Si desea cambiar la constante, es suficiente para cambiarlo en un solo lugar

yo prefiero usar static const NSString* static NSString* const porque es un poco más seguro que #define. Tiendo a evitar el preprocesador a menos que realmente lo necesite.

Answer 2

No se garantiza que al usar @"foo" en múltiples lugares, el tiempo de ejecución use el mismo almacenamiento para ellos, y ciertamente no puede ser el caso en la unidad de compilación o los límites de la biblioteca.
Prefiero usar static NSString *string = @"foo", especialmente con muchas cadenas literales.

Answer 3

Debe hacer la variable estática const.

Una diferencia entre la variable estática y una macro es que las macros no funcionan bien con los depuradores. Las macros tampoco son tipo seguras.

Gran parte de los consejos static-var-vs-macro para C y C++ se aplica a Obj-C.

Answer 4

Supongo que es para protegerme de hacer un error tipográfico en el nombre del identificador que el compilador no capte.

Correcto. Es solo práctica básica de programación defensiva. El resultado compilado (con suerte) es el mismo de cualquier manera.

pero si es así, podría no acabo:

#define kCellId @"CellId" 

y evitar la NSString * poco estática? ¿O me estoy perdiendo algo?

Sí. Pero el símbolo kCellId se definiría globalmente, al menos en su unidad de compilación. La declaración de una variable estática hace que el símbolo sea local para ese bloque.

Normalmente verá las constantes de cadena definidas como variables globales o variables estáticas en lugar de definir el preprocesador. Esto ayuda a garantizar que solo se trata de una única instancia de cadena entre diferentes unidades de compilación.

Answer 5

Me encanta todas las respuestas aquí sin un ejemplo sencillo de cómo declarar correctamente uno ... para ...

Si desea que la constante de estar visible externamente (es decir. "Global") ... . declararlo como tal en una cabecera ...

extern NSString *const MyTypoProneString;

y definir en un archivo .m, FUERA cualquier @implementation como ...

NSString * const MyTypoProneString = @"iDoNtKnOwHoW2tYpE";

Dicho esto ... si simplemente desea una static const que es local a su implementación de la clase (o incluso un cierto método!) ... simplemente declarar la cadena DENTRO la implementación (o método) como ...

static NSString *MavisBeacon = @"She's a freakin' idiot";

EDITAR Aunque muestro cómo hacer esto ... todavía tengo estar convencidos de que este estilo es de ninguna manera mejor que el, más simple y menos repetitivas Declaración única ridículamente corto, al estilo de ..

#define SomeStupidString @"DefiningConstantsTwiceIsForIdiots" 

Usa #define 's son mucho menos molestos ... Solo que no permitas que el preprocesador-jugador-enemigo te deprima.

Answer 6

Por lo tanto, estoy entrando en esto un poco tarde, pero esto se ha preguntado muchas veces de varias maneras en las áreas C/C++ de SO, pero básicamente aquí hay una versión ampliada de mi comentario a alex gray:

Cada vez que piense que debería usar un #define para macros de cadena, lo más probable es que no deba hacerlo. La razón es porque las macros #define son básicamente reemplazos de expresiones regulares para el preprocesador. Cada vez que el preprocesador ve una macro llamada, la reemplaza con lo que sea que haya definido. Esto significa que una nueva cadena literal cada vez se asignará a la memoria, lo que es realmente malo en lugares como identificadores de reutilización de celda (por lo que el código de UITableViewController de Apple usa una estática).

El uso de const externo/estático apunta todas las referencias a un solo lugar en la memoria, como mencionó Eonil. Esto es mucho más eficiente y eficiente en la memoria, lo cual es muy importante en los dispositivos móviles.