[Objective-C] Gestion de la mémoire

Gestion de la mémoire [Objective-C] - Divers - Programmation

Marsh Posté le 20-05-2010 à 12:12:37    

Bonjour,
 
Je travaille actuellement sur une petite appli iPhone et je traque actuellement les leaks que j'ai.
En cherchant leur raison je suis tombé sur cette page: http://stackoverflow.com/questions [...] bjective-c
Où il est dit que ce code:

Code :
  1. self.aController = [[AController alloc] init];
  2. ...
  3. [self.aController release];


Cause du leak, car à la fois "[AController alloc]" et "self.aController =" incrémentent le compteur de référence de l'objet du fait de la propriété "retain" de self.aController. Donc qu'après le release il reste à 1, et l'objet n'est pas réellement libéré.
La solution serait donc de passer par un pointeur temporaire:

Code :
  1. AController *tempAController = [[AController alloc] init];
  2. self.aController = tempAController;
  3. [tempAController release];
  4. ...
  5. [self.aController release];


 
Mais cela me paraît étrange. Tout ça rendrait au final la gestion de la mémoire plus compliquée qu'un simple new/delete sans ramasse miettes, en créant un genre de shared_ptr mal géré puisque l'on doit explicitement déclarer la fin de vie d'une référence.
 
Ai-je mal compris quelquechose?

Reply

Marsh Posté le 20-05-2010 à 12:12:37   

Reply

Marsh Posté le 20-05-2010 à 17:12:03    

C'est uniquement si ta propriété self.aContainer possède l'attribut "retain" que tu dois faire :

Code :
  1. AController *tempAController = [[AController alloc] init];
  2. self.aController = tempAController;
  3. [tempAController release];

Et dans ce cas, la ligne:

Code :
  1. [self.aController release]

n'est pas utile, ce sera fait automatiquement par la propriété à la destruction de ton self.
 
(Mais c'est vrai qu'avoir un truc qui ferait le release tout seul quand le scope de tempAController ferait pas de mal...)


Message édité par 0x90 le 20-05-2010 à 17:12:38

---------------
Me: Django Localization, Yogo Puzzle, Chrome Grapher, C++ Signals, Brainf*ck.
Reply

Marsh Posté le 21-05-2010 à 11:17:02    

Ah, il n'est pas nécessaire de surcharger dealloc() pour y mettre les release de chaque propriété?

Reply

Marsh Posté le 21-05-2010 à 11:42:39    

Raziel a écrit :

Ah, il n'est pas nécessaire de surcharger dealloc() pour y mettre les release de chaque propriété?


 
Ah ben si, oops [:cupra]
 
Du coup effectivement, c'est un shared_ptr mal non géré, faut faire absolument tout les ref/unref à la main :/
 
Et c'est encore pire, si on veut être parfaitement propre il faut faire:

Code :
  1. [aController release];

En utilisant la var et pas la property, pour éviter de déclencher les signaux d'objets qui observent la propriété.
 
Mouais, pas top tout ça :/


---------------
Me: Django Localization, Yogo Puzzle, Chrome Grapher, C++ Signals, Brainf*ck.
Reply

Marsh Posté le 21-05-2010 à 12:02:36    

Ok, c'est bel et bien dégueu :D
Je me demande pourquoi implémenter un tel truc si au final ça ne constitue pas une aide... new/delete (+ valgrind :o )feraient aussi bien le boulot avec moins de prise de tête :/

Reply

Marsh Posté le 21-05-2010 à 14:59:01    

Bah avec new/delete c'est pas facile de gérer la durée de vie d'un objet partagé par plusieurs autres. Les shared_ptr sans la partie automatique c'est assez courant en fait (gtk, l'implé de python et d'autres languages interprétés, etc...). En C t'as pas trop le choix de toute façon, t'as pas moyen d'exécuter de code quand un truc sors du scope.
 
Par contre ouais, c'est étonnant qu'à l'époque vu qu'ils se sont permis de bidouiller et étendre le C, ils aient pas pensé ou désiré cette fonction (bon maintenant ils ont pris une autre approche vu qu'il y a un GC... ça règle le problème.)


---------------
Me: Django Localization, Yogo Puzzle, Chrome Grapher, C++ Signals, Brainf*ck.
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed