Surveiller ses dealloc
Mala
Membre, Modérateur
Je pensais vous livrer cette catégorie l'autre soir mais je me suis rendu compte que j'avais un problème avec les héritages. Du coup, j'ai préféré supprimer mon poste en attendant. Voilà qui est corrigé ce soir. Cette catégorie est un peu dans l'esprit de ce qu'a fait Ali dans ce poste mais dans le sens préventif.
Une règle de codage des "vétérans" c'est de mettre systématiquement un pointeur à nil après un release. On évite ainsi bien des surprises de violations d'accès. Cette catégorie se base sur ce postula pour surveiller et afficher un log lors d'une déallocation suspecte.
Pour l'utiliser, il suffit d'implémenter la méthode "deallocControl:" de la sorte dans la classe que l'on veut surveiller:
A l'exécution, dès que l'objet est libéré, on a un joli log:
Une fois le développement du projet terminé, il suffit de passer le define "DEALLOC_CONTROL_ACTIVATED" à 0 dans le .h de la catégorie pour éviter toute perte de performances du fait des contrôles. Cette approche me plaà®t bien car elle reste dans l'esprit de la gestion mémoire manuelle d'Obj-C avec un côté "conduite accompagnée".
J'espère que cela sera utile à d'autres.
/cliccool.gif' class='bbc_emoticon' alt=' 
' />
Edit: après mise en production fructueuse de mon côté, je propose de passer le post en HQ.
Une règle de codage des "vétérans" c'est de mettre systématiquement un pointeur à nil après un release. On évite ainsi bien des surprises de violations d'accès. Cette catégorie se base sur ce postula pour surveiller et afficher un log lors d'une déallocation suspecte.
Pour l'utiliser, il suffit d'implémenter la méthode "deallocControl:" de la sorte dans la classe que l'on veut surveiller:
<br />
- (void) dealloc<br />
{<br />
[myString release];<br />
myString = nil;<br />
<br />
// Oups on oublie de libérer un objet<br />
//[myString2 release];<br />
//myString2 = nil;<br />
<br />
// Notre ceinture de sécurité...<br />
[MaClasse deallocControl:self];<br />
<br />
[super dealloc];<br />
}<br />A l'exécution, dès que l'objet est libéré, on a un joli log:
Console d' a écrit: »
Class "MaClasse" - Instance variable "myString2" != nil - Potential memory leak?
Une fois le développement du projet terminé, il suffit de passer le define "DEALLOC_CONTROL_ACTIVATED" à 0 dans le .h de la catégorie pour éviter toute perte de performances du fait des contrôles. Cette approche me plaà®t bien car elle reste dans l'esprit de la gestion mémoire manuelle d'Obj-C avec un côté "conduite accompagnée".
J'espère que cela sera utile à d'autres.
' />Edit: après mise en production fructueuse de mon côté, je propose de passer le post en HQ.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
MERCI Mala, tu vas sauver la galaxie avec ça ! lol
Je testerai dans mon prochain projet!
Merci!
Seul problème, ça ne détecte les leaks potentiels qu'à l'exécution et non à la compilation... (bon je sais, on peut pas mieux faire c'est pas de ta faute :P et c'est déjà super bien... c'est juste dommage que l'analyse statique (Clang) de Xcode 3.2 ne les détecte pas tous donc justement de ce côté ça peut vachement aider !)
Oui c'est même surprenant. C'est une vraie passoire en ce qui concerne les variables d'instance.
NSObject+DeallocControl.h
NSObject+DeallocControl.m