Objet d'allouer et d'init en Objective-C

Quelle est la différence entre les 2 façons de répartir et d'initialisation d'un objet?

AController *tempAController = [[AController alloc] init];
self.aController = tempAController;
[tempAController release];

self.aController= [[AController alloc] init];

La plupart des apple exemple d'utiliser la première méthode. Pourquoi voudriez vous allouer, init et de l'objet, puis relâchez immédiatement?

InformationsquelleAutor Ronnie Liew | 2008-10-01

70

Chaque objet dispose d'un compteur de référence. Quand il passe à 0, l'objet est libéré.

En supposant que le bien a été déclaré comme @property (retain):

Votre premier exemple, ligne par ligne:
1. L'objet est créé par alloc, il a un nombre de références 1.
2. L'objet est remis à self's setAController: méthode, qui envoie un retain message (parce que la méthode ne sait pas où l'objet est à venir à partir de), incrémenter son compteur de référence à 2.
3. Le code d'appel n'a plus besoin de l'objet lui-même, donc il appelle release, décrémenter le compteur de référence à 1.
Votre deuxième exemple fait les étapes 1 et 2 mais pas 3, donc à la fin de l'objet de comptage de référence est de 2.

La règle est que si vous créez un objet, vous êtes responsable de la relâcher lorsque vous avez terminé avec elle. Dans votre exemple, le code est fait avec tempAController après il définit la propriété. C'est la méthode de définition de la responsabilité de faire appel retain si elle a besoin de cet objet pour rester dans les parages.

Il est important de se rappeler que self.property = foo; en Objective-C est vraiment juste un raccourci pour [self setProperty:foo]; et que le setProperty: méthode sera retenue ou de la copie d'objets que nécessaire.

Si le bien a été déclaré @property (copy), l'objet aurait été copié à la place de retenue. Dans le premier exemple, l'objet d'origine serait libéré immédiatement; dans le deuxième exemple, l'objet original de comptage de référence serait de 1, même si elle devrait être 0. Si vous le souhaitez écrire votre code de la même façon.

Si le bien a été déclaré @property (assign), puis self n'est pas revendiquant la propriété de l'objet, et quelqu'un d'autre doit le conserver. Dans ce cas, le premier exemple serait incorrect. Ces sortes de propriétés sont rares, habituellement utilisée uniquement pour objet de délégués.
- C'est seulement le cas si 'aController" est déclarée avec les @property(retenir), bien que, droite?
- Qui est correct.
- C'est aussi le modèle correct si la propriété est déclarée (copie). Le deuxième modèle est correct pour une propriété déclarée (attribuer) (ou avec la collecte des ordures activé).
- C'est le "accepté" réponse, mais je vous conseille fortement de lire mmalc la réponse ci-dessous. Il montre comment le faire de plus en plus pratique (avec une minuscule, minuscule, minuscule effet sur les performances).
- wow, je ne savais pas objective-C de comptage de référence a été tellement mal mis en œuvre. Même le c++ n'est-il mieux avec shared_ptr (pas de ridicule à choisir pour temporals, pour commencer)
- Beaucoup de choses ont changé depuis que cela a été demandé et répondu; lecture Automatique de Comptage de Référence si vous êtes réellement intéressés à Objective-C gestion de la mémoire (et pas seulement ici pour poster snark).
- déjà appris, et de découvrir que le Pimpl avec des implémentations des objets C++ dans .mm est la meilleure approche pour mon exigence, merci pour la réponse,.. Btw il n'y a rien de mal avec snark lors de son vrai 😉
- Quel est le problème avec le snark est qu'elle vous fait paraître comme un pauvre ingénieur.
InformationsquelleAutor benzado
30

Comme d'autres l'ont noté, les deux extraits de code vous montrer ne sont pas équivalents (pour la gestion de la mémoire raisons).
Pourquoi le premier est choisi sur celle-ci:

La formulation correcte de ce dernier serait
```
self.aController= [[[AController alloc] init] autorelease];
```
Par rapport à l'ancien, ce qui ajoute une charge supplémentaire grâce à l'utilisation de l'autorelease pool, et dans certaines circonstances conduira à la durée de vie de l'objet inutilement prolongée (jusqu'à ce que l'autorelease pool est sorti), qui permettra d'augmenter la mémoire de votre application empreinte.

L'autre "possible" mise en œuvre (selon l'endroit où l'exemple est tiré d') est tout simplement:
```
aController = [[AController alloc] init];
```
Toutefois, la définition d'une variable d'instance directement est fortement déconseillé de n'importe où ailleurs que dans un ou init méthode dealloc. D'ailleurs vous devriez toujours utiliser des méthodes accesseurs.

Cela nous amène alors à la mise en œuvre illustré dans l'exemple de code:
```
AController *tempAController = [[AController alloc] init];
self.aController = tempAController;
[tempAController release];
```
Ce suit les meilleures pratiques depuis:
- Il évite autorelease;
- Il fait de la gestion de la mémoire sémantique immédiatement clair;
- Il utilise une méthode d'accesseur pour définir la variable d'instance.
- mmalc du droit. Mais ... dans la pratique, les 3 lignes de code à attribuer à 1 variable est tout simplement fou. La plupart des équipes que j'ai vu utiliser le autorelease "tout faire en une seule ligne de code" d'approche de la surcharge est EXTRÊMEMENT petite. Si vous avez jamais touché à une situation sur iPhone, où il fait une grande différence en termes de performances, vous devriez probablement être réécrire le code en C de toute façon - vous faites trop de répartition. Peu d'équipes iront se coller à la "officielle" de la convention (à juste titre à mon humble avis - dans le monde réel des programmes doit être clair, mais pas au point de la diarrhée verbale).
InformationsquelleAutor mmalc
5

Note également que votre désir de réduire le code pour une ligne qui est pourquoi beaucoup de gens utilisent Autorelease:
```
self.aController = [[[AController alloc] init] autorelease];
```
Si, en théorie, sur l'iPhone autorelease est en quelque sorte plus cher (jamais entendu parler d'une explication claire pourquoi) et donc vous pouvez libérer explicitement à droite après l'affectation de l'objet par ailleurs.
- Je ne pense pas que c'est plus cher que autorelease dans le Cacao. Juste que autorelease est plus cher que de sortir. Donc, si vous pouvez libérer de l'objet au lieu de autoreleasing vous devriez le faire.
- autorelease est plus cher parce qu'il a de trouver un thread locale de la structure de données et d'y ajouter (l'autorelease pool), alors que la libération juste décrémente un entier (le nombre de références).
- Oui, la question était de savoir pourquoi est-autorelease plus cher sur iPhone, pas pourquoi c'est plus cher que de sortir.
- Je n'ai jamais autorelease, à moins que je..
InformationsquelleAutor Kendall Helmstetter Gelner
5

Si vous êtes en utilisant Xcode, il peut vous aider à détecter ce genre de code avec l'analyseur statique.
Il suffit de frapper Build >> Construire et Analyser

Cela va vous montrer très utile message à ces morceaux de code.

InformationsquelleAutor leviathan
4

Une autre chose à noter est que votre exemple, dépend de la @définition de propriété de aController aussi.

Si elle a été définie comme @property (readwrite, retain) id aController; alors votre exemple, alors que si elle est définie comme @property (readwrite, assign) id aController; puis l'appel supplémentaire à la libération serait la cause de votre objet à être libéré.
- Il n'y a pas de point de en précisant readwrite, puisque c'est la valeur par défaut.
InformationsquelleAutor Ashley Clark
2

Vous pouvez également faire de
```
@property (nonatomic, retain)AController *aController;
...
self.aController= [[AController alloc] init];
[aController release];
```
avec une retenue à la propriété, et il devrait fonctionner de la même manière, mais de son mieux pour utiliser l'autre sens (pour conserver les propriétés) parce qu'il est moins à confusion, que le code fait ressembler à vous attribuer aController et puis il est supprimé de la mémoire, alors qu'en réalité, ce n'est pas parce que setAController le retient.
- Ce serait encore pire si c'est une copie de la propriété. Vous seriez en relâchant la copie, en laissant un objet mort dans la variable d'instance, et la fuite de l'objet que vous allocked et inited.
- Mais il fonctionne si elle est retenue. Non pas que vous devriez le faire.
- En fait je pense que c'est une bonne approche si vous connaissez la propriété est de conserver la propriété. Cela enlève un peu de l'encombrement de code.
InformationsquelleAutor mk12

Vous devez vous connecter pour publier un commentaire.