Sto provando a calcolare i pro e i contro di @""
e [NSString string]
in quanto sembrano comportarsi in modo simile. Suppongo che speri che [NSString string]
restituisca un valore statico evitando così inutili creazioni di stringhe in memoria. Qualcuno può far luce perché la documentazione è inconcludente.@ "" rispetto a [NSString string]
risposta
È molto probabile che sia @"" == [NSString string]
e quindi la decisione è solo una questione di stile. Aha, non lo è:
NSLog(@"%i", @"" == @""); // 1
NSLog(@"%i", [NSString string] == [NSString string]); // 1
NSLog(@"%i", [[NSString string] stringByAppendingString:@"foo"] ==
[@"" stringByAppendingString:@"foo"]); // 1
NSLog(@"%i", @"" == [NSString string]); // 0
Ma non riesco a pensare a nessun caso d'uso in cui la differenza sarebbe importante.
+1 * ma * la tua seconda riga dimostra la speranza dell'OP. il quarto non è rilevante (qui).'[NSString string]' restituisce il letterale o statico della fondazione e '@" "' restituisce il letterale esportato dall'immagine. sarebbe rilevante se l'OP avesse bisogno di confrontare i puntatori, ma non è un requisito qui. '@" "' sarebbe il più veloce, ma la maggior parte delle persone non si preoccuperebbe della differenza di velocità. se l'OP avesse un sacco di confronti tra stringhe da fare e il confronto tra puntatori fosse un buon adattamento, allora il risultato di '[NSString string]' potrebbe essere più veloce. – justin
Se la quarta riga era vera, penso che la discussione sarebbe per lo più discutibile, ecco perché l'ho inclusa. Grazie per i chiarimenti! – zoul
ah, ok - e prego. – justin
Sono abbastanza sicuro che [NSString string]
è semplicemente un metodo di convenienza per [[[NSString alloc] init] autorelease]
, che è identico a @""
in semantica.
Ciò significa che non vi è alcun vantaggio di memoria.
@""
è una stringa letterale e sarà presente durante l'esecuzione dell'applicazione. [NSString string]
è probabilmente un oggetto allocato dinamicamente (ma può essere ottimizzato per non essere) e così potrebbe (in teoria) essere raccolto durante l'esecuzione quando non è più referenziato. Sia le stringhe letterali che quelle allocate dinamicamente utilizzano la condivisione internamente, quindi è probabile che due @""
o due [NSString string]
restituiscano lo stesso oggetto, anche se non nello stesso file, ma non è garantito che lo faranno. Tuttavia, potrebbero non restituire lo stesso oggetto l'uno dell'altro.
Nel complesso non importa, non si deve fare affidamento sull'uguaglianza dei puntatori per verificare l'uguaglianza delle stringhe.
Guardando il codice di assemblaggio direi che @""
ha il vantaggio sulle prestazioni, ma pensare che sia importante è davvero un caso di ottimizzazione prematura.
Basta usare @""
, ha il merito di essere breve e chiaro.
Non credo che Rob voglia confrontare le stringhe usando i puntatori, questo è stato solo il mio test per scoprire le ottimizzazioni nascoste dietro diversi costruttori di stringhe. – zoul
@ "" è una stringa costante, quindi i messaggi -retain, -release e -autorelease vengono ignorati. Inoltre non può essere deallocato.
[Stringa NSString] è già autorizzata.
C'è solo una cosa qui che conta, per me: che quello che sto usando è una stringa veramente vuota. Ogni singola volta Vedo [NSString string]
, sono garantito al 100% per ottenere una stringa con un .length
di 0
.
Tuttavia, quando vedo @""
, non sono sicuro al 100% che sia vuoto. Ora, 99,999%, questa è una scommessa sicura, ma potrebbe essere altrettanto facilmente (zero-width space), backspace, zero-width non-joiner, ecc. Si spera che il codificatore sadico che ha usato questo messaggio abbia messo vicino un commento dicendo che è uno spazio a larghezza zero, ma solo così il mio codice non è così confuso, io uso [NSString string]
.
@ "" è utilizzato per svuotare una NSString. La stringa viene utilizzata per svuotare 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. Swift: String contiene String (senza utilizzare NSString)?
- 2. Conteggio stringa rapido() rispetto a NSString. Lunghezza non uguale
- 3. Come convertire std :: string in NSString?
- 4. "Unicode" rispetto a "String" con SQLAlchemy e PostgreSQL
- 5. Come aggiungere una NSString a un'altra NSString
- 6. Conversione lunga NSString a NSNumero
- 7. Motivi per utilizzare le costanti NSString rispetto alle enumerazioni?
- 8. Convertire NSDate a NSString
- 9. convertire NSDictionary a NSString
- 10. NSString a NSUInteger
- 11. Conversione NSDecimalNumber a NSString
- 12. NSString a NSDate
- 13. Codifica da NSData a NSString
- 14. Objective C UIColor a NSString
- 15. NSString - Unicode a ASCII equivalente
- 16. iPhone SDK NSString a NSDate
- 17. aggiungendo puntini di sospensione a NSString
- 18. parallel.foreach - loopState.Stop() rispetto a Cancellazione
- 19. Uguale a (=) rispetto a LIKE
- 20. php hash string string a integer
- 21. YAML rispetto a XML
- 22. UIStoryboardSegue rispetto a presentviewcontroller?
- 23. Crucible rispetto a Gerrit?
- 24. JSON.stringify rispetto a serializzazione
- 25. Quali sono i vantaggi dell'uso di StringIO in Ruby rispetto a String?
- 26. Flex String a XML
- 27. 'System :: String ^' a 'LPCWSTR'
- 28. Java ByteBuffer a String
- 29. Convertire JsonObject a String
- 30. gamma String a Scala
Solo per aggiungere alla risposta qui sotto. Una volta compilato il valore letterale @ "Foo". Qualsiasi altro valore letterale @ "Foo" sarà puntato al primo. – RobCroll