[Gestion Mémoire] Libérer les statiques et singleton ?
ClicCool
Membre
Bonjour,
Je sais bien qu'à la fermeture d'une appli toute sa mémore est libérée d'un coup sans procéder aux dealloc un par un.
Pourtant je ne peut m'empécher de coder le dealloc de mon App Delegate par exemple, qui pourtant ne sera libéré qu'au moment de quitter l'appli...
Mais comment faire alors pour libérer quelques objjets statiques alloués dans le initialize d'une classe ?
Est-ce bien judicieux de le faire du reste ?
Et à ce sujet quelles sont vos habitudes ?
Je sais bien qu'à la fermeture d'une appli toute sa mémore est libérée d'un coup sans procéder aux dealloc un par un.
Pourtant je ne peut m'empécher de coder le dealloc de mon App Delegate par exemple, qui pourtant ne sera libéré qu'au moment de quitter l'appli...
Mais comment faire alors pour libérer quelques objjets statiques alloués dans le initialize d'une classe ?
Est-ce bien judicieux de le faire du reste ?
Et à ce sujet quelles sont vos habitudes ?
- Vous laisser la fermeture de l'appli libérer tous les objets 'root' ?
- Vous codez un dealloc pour tous les objets qui ne seront désalloué qu'en fin de programme ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
On ne peut libérer que des objets qui ont été créées de manière dynamique , c'est-à -dire que l'on a fait un alloc ou un malloc .
Ben, y'a pas d'alloc quand dans l'Initialize d'une classe j'ai un: ???
Tu dois pouvoir faire: [typeAttrb release] dans dealloc
Sauf que je viens de faire un test:
Je quitte l'appli et dans les logs j'ai:
;D
D'autant que si c'est juste un release pour libérer la mémoire, qu'il soit fait ou que l'objet soit libéré par un ménage "global" à la fermeture de l'appli, ça n'a pas trop d'incidence.
Mais j'ai des objets qui font quand même des choses importantes dans leur dealloc. Par exemple un objet manipulant un socket, je fait un close() sur le socket quand l'objet est désalloué. Si je ne fais pas le close(), le socket est bloqué (et le système met du temps à le relâcher, ce qui peut en plus bloquer un lancement suivant de l'appli, embêtant !!)
Du coup parfois c'est problématique que le dealloc ne soit pas appelé... Mais tu as toujours la méthode de l'ApplicationDelegate "applicationWillTerminate" qui te permet de t'en sortir et de quand même faire des choses avant que l'appli ne quitte.
Dans le dealloc de quoi ?
ici typeAttrb est une statique de la classe initialisée dans le +(void)Initialize de la classe.
Pas question que le dealloc d'une 'simple' instance relache cette statique ...
C'est pour cela que je te parlais de l'alternative applicationWillTerminate: de NSApplicationDelegate (ou UIApplicationDelegate pour iPhone).
Absolument d'accord moi aussiÂ
Ici tu parles d'un appDelegate donc il n'y a qu'une seule instance, ce qui limite l'utilité des statiques ...
Je pense qu'il n'y a pas 36 solutions, comme le dit Aligator "applicationWillTerminate" is the way to go
Oups, je me suis mal exprimmé
Je parlais du problème de la libération d'objects comme l'AppDelagate mais aussi d'Objects statiques d'autres classes.
Ici, précidemment, typeAttrb est une statique d'une classe mère ayant de nombreuses sous classes, elles mêmes étant instanciées de nombreuses fois.
P.S. je manque à tous mes devoirs !
Content de te lire MPergand
C'est la 2e fois que tu me la fais, mais je comprends toujours rien
Pour dire vrai je me souviens plus très bien d'où m'était partie ce joke. :P
Il me semble que c'était en rapport avec un de tes anciens avatar ? ... (un panneau de signalisation ou un truc du genre non ?)
??? je n'utilise jamais d'avatar !
pour revenir au sujet:
Une alternative possible est que toutes les fenêtres ouvertes reçoivent un close et donc il est possible d'intercepter l'événement via un window delegate.
Donc à priori il suffit, pour chaque objet pour lequel tu veux faire un truc particulier à la fermeture de l'appli, de mettre le code adéquat dans la méthode que tu associes à ta notification en plus ou à la place de le mettre dans le dealloc (selon le cas).
Bon attention, je ne suis pas sûr que l'ordre d'appel soit fiable : si tu as plusieurs observeurs de ta notification, vérifier que ça ne risque pas d'être appelé deux fois (et dans quel ordre, pas forcément défini) sur la superclass si à la fois ta classe et sa superclass sont observer... ce genre de trucs, quoi, si tu as des objets dépendants les uns des autres, ça ne va pas forcément suivre la hiérarchie selon la façon dont tu vas coder ça.
Mais bon ça me semble une alternative intéressante si ça peut te faciliter la vie.
Mon soucis c'est qu'il est hors de question de relacher mes statiques tant qu'il reste, ne serait-ce qu'une seule instance des classes filles en circulation, ce que applicationWillTerminate: ou la notif NSApplicationWillTerminateNotification ne me garantissent pas il me semble ...