Oui, les NSStrings (chaînes littérales) codées en dur (c'est-à-dire tout @"..."
dans votre code source) sont transformées en chaînes de caractères qui existent indéfiniment pendant l'exécution de votre processus.
Cependant NSArray 's containsObject:
appels de méthodes isEqual:
sur ses objets, d'où même une chaîne créée dynamiquement comme [NSString stringWithFormat:@"%d", 2]
rendrait YES
dans votre exemple de code.
C'est parce que l'élément NSString isEqual:
(ou plus précisément son isEqualToString:
) est mise en œuvre pour être connaissance du contenu (par opposition à la comparaison des identités des pointeurs) et renvoie donc YES
pour toute paire de chaînes de caractères contenant la même séquence de caractères (au moment de la comparaison), peu importe comment et quand elles ont été créées.
Pour vérifier l'identité des pointeurs, il faut énumérer les tableaux et les comparer par l'intermédiaire de
NSString *yourString = @"foo";
BOOL identicalStringFound = NO;
for (NSString *someString in stringArray) {
if (someString == yourString) {
identicalStringFound = YES;
break;
}
}
(ce que vous ne voudriez probablement pas, cependant).
Ou d'une manière plus pratique :
BOOL identicalStringFound = [stringArray indexOfObjectIdenticalTo:someString] != NSNotFound;
(vous ne voudriez probablement pas de celle-ci non plus).
En résumé :
Donc la raison pour laquelle vous avez une réponse positive de containsObject:
es PAS car les chaînes littérales partagent la même instance de constante, MAIS parce que containsObject:
par des appels de convention isEqual:
qui est conscient du contenu.
Vous pouvez lire la documentation (succincte) de l'application isEqual:
de la Protocole NSObject .