SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> wrote:
Ben je croyais qu'une fonction quand elle avait fini son boulot libérait
la mémoire ?
(tant qu'on n'attaque pas des variables globales ...)
"on" m'a dit (sur clj) qu'il n'y a rien de spécifié à ce sujet...
au pire, à mon idée, tu restes avec la dernière restauration(*), non ?
Est-ce grave ?
ben dans mon cas, je vois très bien dans le canvas qu'il y a un pb : ça
donne des lignes suplémentaires...
(*) et encore ? pas certain puisque "return this"
ça (ie le return this) c'est pour permettre de chainer les commandes par
ex :
turnRight().goForward().penUp()...
Ne suffit-il pas de se pencher sur le principe-problème des "closures" ?
<http://blogs.developpeur.org/cyril/archive/2007/10/16/prototype-closure-
optimisation-creation-classe-javascript.aspx>
(qui sont un sujet de fuite de mémoire avec IE)
<http://laurens.vd.oever.nl/weblog/items2005/closures/>
où on a une indication du moment où il faut faire : a = null;
je vais lire ça attentivement...
child = null; // ???
ouais, bien sûr, j'ai pensé à ça, mais ça ne change rien, la branche
reste quand même active, le seul moyen **efficace** que j'ai trouvé pour
"tuer une branche" est d'avancer son index à la fin de la chaine
"rule"...
mais bon, il faut que je retrouve ce qu'il faut faire pour détruire un
enfant devenu inutile, car, comme ce principe est récursif, on a très
vite beaucoup de segments tracés...
je viens de mettre en ligne, sur la même page
(<
http://thoraval.yvon.free.fr/Canvas/l_system.xhtml>) le L-System
"Koch" plus "spectaculaire" que mon arbre style cactus...
je dois encore ajouter un angle différent de 90° et ensuite je passe à
une version 3D en VRML...
--
Une Bévue
