2009-09-30 9 views
0

En ce qui concerne ce Why does 'self' protect memory space? affichage, j'utilise « auto » pour accéder aArray. Pourtant, je reçois toujours un objet invalide dans la méthode didSelectRowAtIndexPath:.Même avec soi-même, objet autoreleased encore

Dans le contrôleur racine, j'accéder à aArray comme ceci:

MyAppDelegate *theDelegate = [[UIApplication sharedApplication] delegate]; 
NSString *aKey = [theDelegate.aArray objectAtIndex:0]; 

Would qui ont quelque chose à voir avec aArray perdre sa référence? Pourquoi cela ne se produirait-il pas dans cellForRowAtIndexPath: (la première utilisation en dehors de MyAppDelegate)?

Répondre

1

Si aArray est une propriété qui est définie à retenir, alors vous pouvez être trop relâcher quelque part. Cela ne semble pas tout à fait clair dans votre question, mais si c'est l'objet à l'index 0 qui est invalide, c'est peut-être ça qui a été sur-relâché. Si vous utilisez Xcode 3.2 sur Snow Leopard, vous pouvez vous assurer que vous utilisez l'analyseur statique Clang. Cela peut aider à trouver de telles sur-publications.

+0

Oui - Je suis en cours d'exécution Clang. L'objet à l'index zéro est valide. – 4thSpace

+0

Utilisait 'assign' plutôt que 'retain'. Je n'ai pas attrapé pendant un moment. Problème résolu. – 4thSpace

+0

Donc je suppose qu'au lieu de trop relâcher, il était sous-conservé. –

2

Cette question n'a pas de sens. Ou, plutôt, la réponse est toujours "allez lire et comprendre la documentation liée à la réponse à votre autre question".

Plus précisément:

Il n'y a pas de magie sur la gestion de la mémoire. Il n'y a rien de spécial à propos de l'individu par rapport à tout autre type de référence d'objet. La notation par points est simplement abrégée pour un appel de méthode; rien de spécial non plus.

dans votre code jusqu'à ce que vous comprenez ces choses, vous serez chassez les fantômes et ne pas résoudre réellement les problèmes réels.

Questions connexes