Il y a déjà sous Cocoa un système de garbage collector avec le système des AutoReleasePools. Mais c'est vrai qu'il faut déclarer ces Pools, ce n'est pas un garbage collector implicite.

si ça peut rendre le finder plus stable, pourquoi pas..

ca évite de planter dans le cas suivant : a = [[Object alloc] init] [a release]; [a method]; Donc oui, ca donne une application un peu plus stable, mais c'est pas LA solution qui protège de tout.

- D'où est-ce que vous sortez que Mac OS X a des soucis de mémoire ? - D'où es-ce que vous sortez que la désalocation automatique (comme dans java) rend les applications plus stables ? Ce ramasse-miette est déjà présent au niveau du système, lorsqu'un programme quitte, Mac OS désalloue tout ce qui a été alloué. Le garbage collector permet de gérer les fuites au niveau de l'application, en aucun cas au niveau de l'OS. Le but est surtout de faciliter la vie des mauvais codeurs. Franchement les rédacteurs de MacG, parlez nous des mises à jour de shareware, mais commencez pas à vous la jouer développeurs juste parce que vous avez compris 4 mots sur un site anglais... C'est sans intérêt, et pour vous, et pour nous les développeurs.

Heu tintin, on se calme. Si t'aime pas les news, tu quitte et c'est tout. Je veux dire, la news peux peut-être mal expliquer le concept de garbadge collector (que je ne connais pas du tout, je suis pas programmeur). Ce que je sais par contre c'est que les gars de macgé ne mérite pas ça mais pas du tout. Leur news est probablement très vulgarisé pour qu'un maximum de personne puisse comprendre un peux le concept. C'est interessant, mais ça pourrait être plus étoffée non? J'ai hâte d'en savoir plus sur Léopard. Je parlais de votre article avec Stuff Mc sur le dernier pomcast. Très interessant. Le cousin

OUhla ! Du calme, faut pas s'énerver. C'est gentils si ceux qui s'y connaissent en programation peuvent faire remarquer des erreurs mais faut pas en faire un paté. Ok vous êtes des dieux (dans un domaine ultra specialisé et restreint), vous parlez un langage auquel je comprends rien et dont je dépend, en tant qu'usager ... Mais c'est pas une raison pour se la péter, et ça fait pas de mal de rester un peu sympas, non ? Un simple usager.

[tintin et les autres] Pas à 100% d'accord. Si une applic est utilisée de façon continue sur une longue période, par ex. le Finder, et qu'elle est victime de memory leaks, c'est bien sa stabilité perçue (et celle du système) qui est en danger. Maintenant, un garbage collector n'est pas indispensable, il suffit de savoir ce que l'on fait à l'écriture et de bien tester l'applic, il y a quand même des outils pour ça.

Garbage collector c'est pas un groupe de rock ?

jaime bien ce genre de news ou les commentaires sont pointus avec des mots que personne comprend. sa fait super serieu ;) Ps: cest pas ironique je suis serieu :)

Pour ceux qui n'on jamais utilisé de GC, et qui en savent plus que les autres, il faut savoir que si le GC est actif en Objective C, il ne faut PAS utiliser de dessalocation classique, sous peine de faire merder le GC. Et oui. D'ailleurs, le GC est déjà existant en Objective C, juste qu'Apple ne le propose pas par défaut. On le trouve par défaut par contre avec la version GNU d'OpenStep

Ca aidera pas mal d'applications qui bouffent de la RAM et ne la rendent jamais. Faites un top et vous verrez, ça arrive souvent !

Qui a dit Skype ? :D

Le ramasse-miettes peut entraîner une baisse de performances, et peut-être surtout, (mais je ne connais un peu ça que de façon théorique) des irrégularités de performances (quand le ramasse-miettes s'agite) qui peuvent être gênantes. Ceci dit, on peut très bien vouloir programmer proprement et ne pas avoir envie de s'embêter avec la gestion mémoire qui relève quand même plus des limites physiques des machines que de la beauté de l'algorithmique. Est-ce que beaucoup de programmeurs cherchent à gérer eux-même la mémoire virtuelle ? ou laissent-ils faire ça par le système ? Les gens et les langages qui favorisent l'utilisation du ramasse-miettes m'ont l'air d'avoir des options de rigueur a priori au moins aussi élevées que celles des concepteurs de C, pour parler par euphémisme. OCaml, par exemple, n'a pas vraiment été conçu par des spécialistes de la bidouille ! Dans bien des cas, je ne vois pas pourquoi l'utilisation d'un ramasse-miettes serait plus répréhensible que le choix d'un langage de haut niveau plutôt que de l'assembleur. Et lorsque ça posera réellement des problèmes (ou lorsque les programmeurs auront envie), je suppose que rien n'empêchera de gérer soi-même la mémoire. Tous les goûts sont dans la nature, pour le reste, c'est la qualité finale des logiciels qui dira si les choix sont corrects ou non, pas les a priori.

Moi qui n'y connais rien je dirai a Tintin et d'autres qui se la pete que l'on peux se tromper (personne n'est infaillible) et qu'il s'agit de faire passer un message comprehensible PAR TOUS! Et dans le cas present je trouve cet article reussit (dans le sens ou j'ai reussit a y comprendre quelquechose quand je ne suis pas programmateur). Alors a tte c'est personnes qui se la pete franchement parce qu'elle savent faire 2 ou 3 trucs... ALLEZ AILLEURS SI VOUS ETES PAS CONTENT ! C'est tellement plus facile de rammener sa science et de descendre les autres plutot que de discuter calmement et d'exposer son point de vue. Je peux moi aussi me la peter en balancant du jargon technique ou perssonne ne va rien comprendre et dire que ce que disent les autres c'est de la merde.... A bon entendeur!

Je ne sais pas comment sera implémenté le GC, mais j'ai peur qu'on fasse un bond en arrière et qu'on ait la même chose que sur MacOS 9 (et java), au temps où on devait choisir la taille mémoire utilisée par l'application. Sinon, je trouve que c'est pas mal, car sur Objective C, j'ai du mal à comprendre pourquoi des fois les objets sont libérés tout seul (les NSString dans certains cas), et des fois non (au moins en java, tout se libère tout seul et en C++, il faut tout faire à la main: c'est clair comme ça).

Je crois que le chanteur de garbage collector prend de la drogue! Et pas que les miettes!!! putain d'rock

Dualg4>"Sinon, je trouve que c’est pas mal, car sur Objective C, j’ai du mal à comprendre pourquoi des fois les objets sont libérés tout seul (les NSString dans certains cas), et des fois non" La règle est simple: à chaque fois que tu utilises une méthode dont le nom contient "init" ou "copy", tu devras faire un release ou un autorelease plus tard car dans ces 2 cas, un nouvel objet est créé. Dans les autres cas, pas besoin, car il n'y a pas de nouvel objet créé, mais seulement une référence à un objet existant qui est passée. Enfin, quand tu crées des méthodes, n'oublie pas de respecter cette convention de nommage.

Je vois qu'il y a encore beaucoup de prégugés concernant les ramasses miettes. Théoriquement parlant, on *sait* faire de ramasses miettes qui ne bloquent pas l'application pendant le ramassage (ramasse miettes incrémental), et qui ont des performances excellentes. On sait faire aussi des ramasses miettes qui ne prennent quasi pas plus de temps que le temps passé à faire des malloc()/free(). Dans le cas d'une petite application qui vit peu longtemps, un ramasse miettes c'est donner de la nourriture aux cochons : Le plus simple est de ne pas faire de free() du tout, car le système desalloue toute la mémoire allouée lors de la fin du processus, de toute façon. Il existe des études publiées, qui comparent les temps passés en allocation/desallocation/gestion de la mémoire (recopie d'objets par exemple, en C++, ou mise à jour des compteurs de références, etc.). En comparaison avec des ramasses miettes à jour des connaissances théoriques (= "state of the art"), ben en gros ça se vaut, dès que l'application testée est suffisemment grosse et complexe. Il y a même certaines études où un ramasse miettes sera plus efficace qu'un développeur humain, dans des cas d'applications complexes, et développées en respectant les règles (modernes) d'encapsulation, de réutilisation, et de modularité. Moi je trouve ça super cette systématisation du ramasse miettes dans Cocoa, car je pense qu'apple a les moyens de fournir un ramasse miettes transparent *et* efficace.

Imaginus, Mais oui Skype ! :D

Je comprends rien à cette histoire de groupe de rock "garbage collector" qui aurait pour objectif de boire du cacolac et de ramasser des miettes de drogue pour être efficace!

Je suis évidement pour la mise en place d'un ramasses miettes si la performance n'en souffre pas. Gérer soi-même la libération de mémoire devient ardu quand l'application fait quelques milliers de lignes (ce qui est mon cas). En effet, il faut jongler entre les libérations automatiques (mais que l'on doit explicitement indiquer dans le programme) qui peuvent provoquer une baisse notable des performances d'une application et les cas où l'on doit "retenir" de la mémoire suffisament longtemps. Cela ne m'étonnerait pas que ce ramasse miette fiabilise l'OS (portion de code faiant appel aux "foundations").

merci macgé en tout cas, continuez comme ça, c'est instructif (je fais un peu de dev)

Pouet tu devrais consulter un spécialiste, tu as vraiment un pète au compteur.