Deviner pourquoi vous pourriez être confus, je voudrais ajouter une explication de ce que le deuxième exemple de code fait réellement (et pourquoi ce n'est pas nécessaire). Je pense que vous êtes confus par cette ligne parce que cette ligne est souvent décrite comme "initialisant foo". C'est un peu trompeur. Techniquement, 2 entités différentes sont modifiées ici - le nouvel objet NSMutableDictionary
est créé et la variable "foo" reçoit son adresse.
La ligne crée en réalité un nouvel objet NSMutableDictionary
sur le tas (zone de mémoire dynamique de votre application). Je l'appellerai "Dictionnaire 1". Pour que ce nouvel objet "Dictionary 1" sur le tas puisse être trouvé, son adresse mémoire est stockée dans "foo". Le rôle de "foo" est d'agir comme un index, donc nous pouvons trouver "Dictionary 1".
Alors que nous disons souvent: "foo est un dictionnaire", c'est parce que nous sommes paresseux - la déclaration est techniquement fausse. Correctement: "il y a un dictionnaire sur le tas et foo stocke son adresse mémoire afin que nous puissions le trouver et l'utiliser".
Lorsque vous exécutez ensuite la ligne:
foo = [bar mutableCopy];
vous utilisez l'adresse dans « bar » pour trouver un autre objet (je vais l'appeler « Dictionnaire 2 ») dans le tas, et faire encore un autre objet ("Dictionnaire 3") sur le tas avec les mêmes valeurs. Si vous tenez compte, c'est maintenant 3 objets en existence. Après que "Dictionary 3" est créé, son adresse mémoire est ensuite stockée dans la variable "foo". Ce stockage dans "foo" écrase l'adresse mémoire existante (celle qui pointait vers "Dictionary 1"). Cela signifie que nous n'avons plus de pointeurs sur "Dictionary 1" et que nous ne pourrons jamais le retrouver. C'est pourquoi nous disons que "Dictionary 1" a fui.
J'espère que vous pouvez voir à partir de cette situation pourquoi "Dictionary 1" n'a jamais été nécessaire (vous avez seulement l'intention d'utiliser "foo" pour accéder à la copie, "Dictionary 3").
Ne le relâchez pas. mutableCopy renvoie un objet autoreleased. – NilObject
à partir de la documentation: L'invocateur de la méthode est toutefois responsable de la libération de l'objet renvoyé. – cobbal
@NilObject: Non, ce n'est pas le cas. Voir http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#//apple_ref/doc/uid/20000043-BEHDEDDB –