Estoy tratando de resolver los pros y los contras de @""
y [NSString string]
, ya que parecen comportarse de manera similar. Supongo que espero que [NSString string]
devuelva un valor estático evitando así la creación innecesaria de cadenas en la memoria. ¿Alguien puede arrojar algo de luz ya que la documentación no es concluyente?@ "" versus [cadena NSString]
Respuesta
Es bastante probable que @"" == [NSString string]
y, por lo tanto, la decisión es solo una cuestión de estilo. Aha, no es:
NSLog(@"%i", @"" == @""); // 1
NSLog(@"%i", [NSString string] == [NSString string]); // 1
NSLog(@"%i", [[NSString string] stringByAppendingString:@"foo"] ==
[@"" stringByAppendingString:@"foo"]); // 1
NSLog(@"%i", @"" == [NSString string]); // 0
Pero no puedo pensar en ningún caso de uso en el que la diferencia sea importante.
+1 * pero * su segunda línea demuestra la esperanza del OP. el cuarto no es relevante (aquí).'[NSString string]' devuelve el literal o estático de la base, y '@" "' devuelve el literal exportado por su imagen. Sería relevante si el OP necesita comparar punteros, pero ese no es un requisito aquí. '@" "' sería el más rápido, pero a la mayoría de la gente no le importaría la diferencia de velocidad. si el OP tenía muchas comparaciones de cadenas y las comparaciones con punteros encajaban bien, el resultado de '[NSString string]' puede ser más rápido. – justin
Si la cuarta línea era cierta, creo que la discusión sería en gran parte discutible, es por eso que la he incluido. Gracias por las aclaraciones! – zoul
ah, está bien, y de nada. – justin
Estoy bastante seguro de que [NSString string]
es simplemente un método conveniente para [[[NSString alloc] init] autorelease]
, que es idéntico a @""
en semántica.
Lo que significa que no hay ningún beneficio de memoria en absoluto.
@""
es una cadena literal y existirá durante la ejecución de la aplicación. [NSString string]
es probablemente un objeto dinámicamente asignado (pero puede optimizarse para que no lo sea) y, por lo tanto, podría (en teoría) recopilarse durante la ejecución cuando ya no se hace referencia. Tanto las cadenas literales como las asignadas dinámicamente emplean el uso compartido interno, por lo que es probable que dos @""
o dos [NSString string]
devuelvan el mismo objeto, incluso si no están en el mismo archivo, pero no hay garantía de que lo hagan. Sin embargo, es posible que no devuelvan el mismo objeto como el otro.
En general, no importa, no debe confiar en la igualdad del puntero para probar la igualdad de cadenas.
Al mirar el código de ensamblaje supongo que @""
tiene la ventaja de rendimiento, pero pensar que es importante es realmente un caso de optimización prematura.
Solo use @""
, tiene el mérito de ser corto y claro.
No creo que Rob quiera comparar cadenas usando punteros, esa fue solo mi prueba para descubrir las optimizaciones ocultas detrás de diferentes constructores de cadenas. – zoul
@ "" es una cadena constante, por lo que se ignoran los mensajes de "retener", "liberar" y "liberar". Además, no puede ser desasignado.
[Cadena NSString] ya se ha lanzado automáticamente.
Sólo hay una cosa que importa, para mí: que lo que estoy usando es una cadena realmente vacía. Cada vez veo [NSString string]
, estoy 100% garantizado para obtener una cadena con .length
de 0
.
Sin embargo, cuando veo @""
, no estoy 100% seguro de que está vacío. Ahora, 99.9999%, es una apuesta segura, pero podría ser @""
(zero-width space), backspace, zero-width non-joiner, etc. Afortunadamente, el sádico codificador que usó esto puso un comentario cerca diciendo que es un espacio de ancho cero, pero para que mi código no sea tan confuso, uso [NSString string]
.
@ "" se utiliza para vaciar un NSString. cadena se utiliza para vaciar un NSMutableString.
NSString * string = @"String";
NSMutableString * mutablestring;
[mutablestring setString:@"Mutable String"];
NSLog (@"%@", string); // String
NSLog (@"%@", mutablestring); // Mutable String
string = @"";
mutablestring = [NSMutableString string];
NSLog (@"%@", string); // empty, nothing actually prints in NSLog
NSLog (@"%@", mutablestring); // empty, nothing actually prints in NSLog
//The below statement gives warning.
mutablestring = @"";
- 1. pymssql versus pyodbc versus adodbapi versus ...
- 2. Cómo agregar un NSString a otro NSString
- 3. NSString análisis
- 4. _Expand versus new versus GNU
- 5. Control.ResolveUrl versus Control.ResolveClientUrl versus VirtualPathUtility.ToAbsolute
- 6. metaphone versus soundex versus NYSIIS
- 7. cómo quitar caracteres de NSString después NSString específica
- 8. Java: tamaño de byte de cadena de caracteres Char versus.
- 9. zend-framework versus Kohana versus Symfony
- 10. iOS JSON NSString Parse
- 11. Reemplazar caracteres en NSString
- 12. iPhone - Comparar NSString nil con otro valor NSString devuelve NSOrderedSame
- 13. iOS: Gaza <img...> de NSString (una cadena html)
- 14. ¿Cómo divido un NSString por cada carácter en la cadena?
- 15. IOS: NSString recuperando una subcadena de una cadena
- 16. Objetivo C: ¿Reemplazar parte de la cadena en NSString?
- 17. cómo agregar concatenar NSString múltiple en una cadena de iPhone
- 18. ¿Convertir cadena de maleficio en NSString de texto?
- 19. cómo comprobar si NSString = un valor de cadena específico?
- 20. Crear NSString repitiendo otra cadena un número determinado de veces
- 21. C#: DbType.String versus DbType.AnsiString
- 22. .Net Parse versus Convert
- 23. NSString a NSDate
- 24. NSString (hex) a bytes
- 25. Estructuras versus clases
- 26. NSString a NSURL?
- 27. Dividir NSString en Array
- 28. Convertir NSDate a NSString
- 29. Objetivo C const NSString * vs NSString * const
- 30. $ versus jQuery
Simplemente para completar la respuesta a continuación. Una vez que se compila el valor literal @ "Foo". Cualquier otro literal @ "Foo" será un puntero al primero. – RobCroll