Est-ce que [NSMutableDictionary setValue: valeur forKey: key] conserver NSString clé?
Lors de l'ajout d'éléments à NSMutableDictionary
à l'aide de la setValue:forKey:
méthode (je suppose que cela se généralise à toute NSObject
) le dictionnaire de conserver la deuxième paramètre, la NSString
?
Par exemple:
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSMutableDictionary *dict = [[NSMutableDictionary alloc] init];
NSString *theString = @"hello";
int i;
for (i=0; i<[theString length]; i++){
NSNumber *myInt = [NSNumber numberWithInt:i];
NSString *character = [NSString stringWithFormat:@"%C",[theString characterAtIndex:i]];
[dict setValue: myInt forKey:character];
}
[dict release];
[pool release];
Clairement, il n'y a pas de raison de la libération myInt
dans la boucle, il est conservé par dict
donc il ne peut pas être libéré jusqu'à la fin du code. Mais qui est le vrai même de character
? Ma pensée est que si NSMutableDictionary
magasins de la chaîne en une autre manière, on pourrait alors créer un temporaire de la piscine autour de la boucle et de la libération de ces chaînes au lieu d'attendre jusqu'à la publication du dictionnaire.
Je suis également curieux de savoir pourquoi retainCount
de character
est 7fffffff comme si c'est un NSConstantString
, je m'attends à ce stringWithFormat
de retour d'un NSString
objet qui aurait besoin de soutènement, mais qui ne semble pas être le cas.
- Juste une pointe fine qui ne méritent pas de réponse: dans le code de 10.4 et plus tard, il est généralement préférable d'utiliser [drain de la piscine] au lieu — lors de la GC est sur, les égoutter offre un soupçon qu'il pourrait être un bon moment pour recueillir des anciennes références, alors que la libération devient un no-op. Avec GC, ils fonctionnent de manière identique.
- C'est une vieille question, mais vous avez probablement censé utiliser
setObject:forKey:
à la place. voir ici
Vous devez vous connecter pour publier un commentaire.
Il est très commun dans le Cacao pour
NSString
paramètres à copier au lieu de la conserver. C'est parce qu'on aurait pu tout aussi facilement, étant donné le dictionnaire une instance deNSMutableString
. Parce que la valeur de la chaîne pourrait changer,NSDictionary
fait une copie.Mais, indépendamment de la façon dont
NSMutableDictionary
vraiment fonctionne, vous n'avez pas à vous inquiéter de savoir sicharacter
doit être conservé. Une fois que vous avez passé àNSMutableDictionary
comme un paramètre, c'est vraiment que de la classe de problème pour décider de la façon de stocker les données, à moins que la documentation spécifiquement vous dit que le fait de retenir les objets sont de votre responsabilité.Je n'ai pas trop se soucier de la
retainCount
de n'importe quel objet. À la suite de la conserver le comte d'un objet de trop près peut vous amener vers le bas trous de lapins qui vient de faire tourner vos roues.Enfin, je ne pense vraiment pas que vous avez besoin pour créer votre propre autorelease pool ici. Sauf si vous savez avec certitude que
theString
va être très long, ou vous avez déjà observé utilisation élevée de la mémoire dans les Instruments, l'ajout de l'autorelease pool est inutile d'optimisation.Vous n'avez pas besoin de conserver
character
là, le dictionnaire de la conserve lorsque vous définissez comme une clé et votre propre code n'a pas besoin de le conserver.Vous n'avez pas besoin de s'inquiéter au sujet de pourquoi le conserver le comte n'est pas ce que vous attendez. Peut-être la Fondation de cadre a mi-Mouche-comme le cas d'un chargement de caractère unique
NSString
instances. En tout cas si vous avez la gestion de la mémoire correcte suivant les lignes directrices, vous serez OK indépendamment de ce que le cadre fait en coulisses. http://iamleeg.blogspot.com/2008/12/cocoa-memory-management.html