›

Fuite ou pas ?

fouffouf Membre
22:02 modifié dans API AppKit #1
Voila, j'ai un array d'objets PlotFormula, eux meme ayant la méthode -(BOOL)activated. Je souhaite avoir une méthode pour récupérer dans un nouvel array les objets PlotFormula qui ont le activated == YES. La voila, mais j'ai peur d'avoir créer une fuite mémoire.
- (NSArray *)formulasToGraph<br />{<br />	NSMutableArray *array;<br />	NSEnumerator *e = [formulas objectEnumerator]; //formulas est l&#39;array de depart<br />	PlotFormula *f;<br />	<br />	while(f=[e nextObject]){<br />		if([f activated]){<br />			[array addObject:f];<br />		}<br />	}<br />	return array;<br />}<br />


Ya t'il vraiment une fuite ??

Réponses

  • BruBru Membre
    22:02 modifié #2
    C'est pas une fuite que je vois, c'est un gouffre !
    Il manque l'allocation de array.

    Pour le reste, je ne vois aucune fuite.

    .
  • fouffouf Membre
    22:02 modifié #3
    dans 1109855724:

    C'est pas une fuite que je vois, c'est un gouffre !
    Il manque l'allocation de array.

    Pour le reste, je ne vois aucune fuite.


    A vrai dire, j'ai un peu fait exprés. Mais en fait si je fait un alloc, il faut que je fasse à  la fin un autorelease. J'ai tort ??
  • BruBru Membre
    22:02 modifié #4
    Le alloc/init n'est pas une fuite en soi... Car si tu prends soin de "release" ton tableau plus tard, ça ne posera aucun problème.

    Mais il est plus propre en effet d'utiliser un array "autorelesable". Ainsi, si plus tard tu n'emploies plus ce tableau, il sera détruit.

    .
  • cbrandtcbrandt Membre
    22:02 modifié #5
    non, c'est tout bon si tu ajoutes l'autorelease...
  • fouffouf Membre
    22:02 modifié #6
    En fait, autorelease, c'est un peu le GarbageCollector de Java. Ah, la gestion de la mémoire en Java  ::)
  • ChachaChacha Membre
    22:02 modifié #7
    dans 1109866668:

    En fait, autorelease, c'est un peu le GarbageCollector de Java. Ah, la gestion de la mémoire en Java  ::)


    Si je dis que je ne suis pas d'accord, ça ne va pas lancer un flameware ? Ce n'est pas par pur esprit de contradiction, c'est juste qu'il me semble que l'autorelease n'est semblable à  un garbage collector que d'assez loin !

    Le garbage collector cherche les fuites mémoires dans un graphe de dépendances entre objets. Et tu ne maà®trises absolument pas quand le "release" (finalize) sera fait en java. Du coup, tu n'as qu'une mauvaise maà®trise de la quantité de mémoire utilisée par un programme.

    En Objective-C, tu planifies exactement quand un objet sera détruit. Si tu ne le release pas toi-même, ou ne l'inscrit pas au bassin d'autorelease, il ne sera jamais détruit ! Il n'y a pas de garbage collector tournant en tâche de fond pour trouver ce genre de fuite.
    Par contre, quand un objet est marqué pour l'autorelease, tu sais exactement quand il va être releasé:
    -si c'est toi qui as créé le NSAutoreleasePool, c'est quand tu releasera ce dernier
    -si c'est le autoreleasepool "invisible" habituel, c'est au prochain runloop de l'interface.

    Au passage : quand j'ai écrit "De C++ à  Objective-C", je pensais que c'était une pratique plutôt rare, de créer soi-même des NSAutoreleasePool. Depuis, j'ai révisé mon opinion, car par exemple, dans MozoDojo, il y'a plein d'endroits où je le fais : autour de certaines portions de code que je sais générer beaucoup d'objets temporaires. Du coup, je m'assure qu'ils n'encombreront pas la mémoire au-delà  du bloc que j'ai encadré. Et je fais ainsi de substentielles économies. (Et pour pas cher, car c'est vraiment hyper simple de créer un NSAutoreleasePool. À part alloc, init, et au final release, y'a rien à  faire)!

    +
    Chacha
Connectez-vous ou Inscrivez-vous pour répondre.