Discuter:Ramasse-miettes

Un article de Wikipédia, l'encyclopédie libre.

Sommaire

[modifier] Introduction

L'introduction dit :

  • Il est légèrement incorrect de parler d'un langage à ramasse-miettes, tout comme il est incorrect de parler d'un langage compilé. Ces caractéristiques sont propres à une implémentation du langage.

C'est vrai et faux à la fois, car la conception du langage tient forcément compte de sa présence ou non.

Note qu'on peut brancher un GC (Boehm-Weiser sur un prorgamme C/C++) si on en a besoin. Comme ces langages ne sont *effectivement* pas prévu pour le ramassage, il existe des cas limites où le GC se comporte 'mal'. Aurélien

Par exemple, on imagine mal Lisp sans gestion automatique de la mémoire. Ce ne serait plus du tout le même langage. --81.57.130.154 30 mai 2004 à 17:15 (CEST)

C'est probablement pourquoi l'adjectif légérement est utilisé, il faudrait sans doute rephraser en quelque chose comme "strictement parlant il est incorrect de ..." (dans le sens de pédantique) phe 13 jun 2004 à 10:33 (CEST)
Cette remarque est idiote - dison hors sujet, je l'ai supprimée. Aurélien
Elle provenait de ta traduction de l'article anglais. Je retraduirais ce qui va bien quand j'aurais le temps phe 14 jun 2004 à 06:40 (CEST)
Je sais :) Mais à l'époque je trouvai ça moyen, et là je trouve ça pire. Je pense pas que ce soit un problème de traduction. Aurélien

Ce paragraphe avait été ajouté en tête de l'article:

La gestion manuelle de la mémoire est l'une des sources les plus courantes d'erreur pour un programmeur. Deux types principaux d'erreur peuvent se produire : l'accès à une zone non allouée, ou qui a été libérée, et la non-libération de la mémoire inutilisée (fuites mémoire). Ces erreurs sont parmis les plus difficiles à détecter.

Je l'ai déplacé vers avantages et inconvénients des GC et modifé en:

La gestion manuelle de la mémoire est l'une des sources les plus courantes d'erreur pour un programmeur. Deux types principaux d'erreur peuvent se produire : l'accès à une zone non allouée, ou qui a été libérée, et la non-libération de la mémoire inutilisée (fuites mémoire). Bien que ces erreurs puissent être difficiles à corriger l'utilisation d'outils et de méthodologie approprié permet d'en réduire l'impact, tandis que l'utilisation d'un rammasse-miettes permet de les éliminer complétement.

J'ai laissé la ref à "l'accès à une zone non allouée, ou qui a été libérée," bien que je pense que ce soit orthogonal aux GC. phe 13 jun 2004 à 10:33 (CEST)

[modifier] Persistence d'objet

"Le ramassage de miettes a été conçu pour gérer l'utilisation de la mémoire mais il peut aussi servir à d'autre propos tel que la vérification de type a l'exécution ou la persistance d'objet."

Qu'est-ce que ça veut dire ? C'était dans l'article original ? Aurélien

Je l'ai ajouté. Tout dépend du type de GC utilisé et de sérialisation d'objet que l'on veut, par exemple si on veut sauver un structure de données sur disque on peut à partir du GC connaitre toute les objets atteignables à partir de celui-ci. Le GC peut aussi avoir à sa disposition des informations de types sur les objets permettant de les utiliser pour la verification de type à l'execution ou pour choisir comment effectuer la sauvegarde d'objet sur support persistant. Une meilleur formulation serait "une partie des caractéristiques d'un GC peuvent parfois être utilisé pour implementer ...". L'implémentation du compilatuer Gnu utilise quelque chose de similaire pour gérer la sauvegarde des en-têtes précompilés phe 13 jun 2004 à 21:03 (CEST)
Je veux bien, mais ça devrait plutôt venir à la fin, dans une catégorie applications connexes du ramasse-miettes. C'est sûr que l'atteignabilité sert à mettre en oeuvre de la prévalence ou ce genre de choses, mais j'aimerais qu'on évite le hors-sujet :) Sur l'histoire des types, tu as des liens, des papiers qui parlent de ça ? (ça m'intéresse, jamais entendu parler) Aurélien
Pas retrouver les références au sujet de la vérification de type, je l'ai supprimmer de l'article. J'ai aussi déplacer cette phrase de la section principe vers avantages/inconvénients, tu as raison elle était trés mal placé. Par contre je ne vois pas ou est le hors-sujet, un GC aide a implémenter la persistance en quoi est-ce HS dans le section avantages/inconvénients de GC ? Si on déclare ça HS le reste l'est aussi, ce sont tous des effets de bords de l'utilisation d'un GC phe 14 jun 2004 à 06:40 (CEST)
hmmmm, je ne suis pas sûr de comprendre. Le principe d'atteignabilité sert à la fois pour le GC et la persistence. De là à suggérer que l'algo du GC et de la persistence travaillent main dans la main, il y a un pas. Pour autant que je sache, beaucoup de langages à GC ne fournissent pas "out of the box" la persistence (les lisps, python, perl, ruby, *ml, haskell, etc...). Le rapprochement me paraît excessif. Aurélien
Je pense donc que je vais l'enlever dans pas longtemps, sauf hurlements. Aurélien


La dernière partie (avantages et inconvénients) est bien bordélique. Je crois que je vais sortir mon cutter... Aurélien Au fait, qui a placé al remarque sur GC = (atteignabilité || Comptage de référence) au début de l'article ? Aucun sens de la cohérence, hein ? Camarade, si tu veux contribuer utilement, fait en sorte que tes contributions ne *déséquilibrent* pas le sens de l'article existant. Un peu de respect, m**** :))

J'ai relu l'article, si on considére que le comptage de référence n'est pas un GC alors oui ça peu de sens et il faut supprimé cette phrase et clarifié que le comptage de référence n'est pas un GC et peut-être le déplacer dans un article à part.
A part ça oui, la partie avantages/inconvénients est devenu un peu anarchique, l'ajout de contre-argument dans la méme phrase alourdit le propos.

phe 14 jun 2004 à 06:40 (CEST)

Effectivement, le comptage de référence pourrait mériter un article à part. Des spécialistes ?-) Le comptage de ref est mentionné dans l'article original (et le présent) à la fin, pour dire justement que ce n'est pas du vrai ramassage de miettes ; maintenant, il est clair que je ne suis pas un expert, alors ... Aurélien

[modifier] comprendre

J'ai essayé de comprendre le fonctionnement et l'intérêt du ramasse miette à partir de cet article mais, je le trouve totalement obscur , je programme depuis longtemps et je débute en programmation objet. Je suis persuadée qu' il y a une manière plus simple d'expliquer , il faut vous mettre à la place d'un néophyte. Quel est l'intérêt de faire un tel article s'il ne s'adresse qu'à des spécialistes?

Le passage « Un ramasse-miettes, ou [autres noms] est un [bidule] informatique de gestion automatique de la mémoire. Il est responsable du recyclage de la mémoire préalablement allouée puis inutilisée » n'est pas clair ? Si tu as programmé en C, puis dans quelque langage possédant un ramasse-miette, tu DOIS voir une différence essentielle. jd ❂ 13 mars 2007 à 18:39 (CET)

[modifier] "Ramasse-miettes"

Je ne sais pas ce que vous en pensez, mais personnellement malgré mes années de programmation objet et mes années de cours je n'ai jamais entendu parler de "Ramasse-miettes" mais uniquement de "Garbage Collector". Je ne suis pas contre la francisation des termes lorsque c'est réellement l'usage, mais ici je ne crois pas que ce soit le cas, je trouve ça plutôt un peu ridicule. Il ne faut pas non plus diaboliser systématiquement tout terme sous prétexte qu'il vienne de l'anglais (on dit bien "internet", "week-end", etc.)

J'aime bien le terme ramasse-miettes et je l'ai déjà entendu assez souvent. Pas chez ma boulangère, mais sur de nombreux articles sur « Le Internet ». -- haypo 8 septembre 2007 à 00:26 (CEST)