Garbage Collector, Ramasse miettes ou Vide ordure (à votre convenance)....
LeChatNoir
Membre, Modérateur
Salut !
J'ai entendu plusieurs fois le terme "Garbage Collector" ces derniers temps. Une fois pour "Liger", une fois au boulot sur un script Perl.
J'ai entendu sur ce site que c'était pour les développeurs qui développe avec leurs pieds...
Bref, tout cela a attisé ma curiosité donc je me suis un peu renseigné et je vous livre le fruit de mes recherches.
Un garbage Collector donc, c'est un système qui permet au développeur de s'affranchir de la gestion de la mémoire.
Typiquement, en Objective-C, plus besoin de se préoccuper des alloc/init et des retain/release/autorelease.
Bon, c'est vrai que pour ceux qui se sont penché sur le pb, on peut dire "ouais bon, ca sera plus cool mais pas de quoi fouetter un ....aà¯e..".
D'autres disent que ca impacte les performances lors de l'exécution.
Mais j'ai trouvé un gars qui a l'air de comprendre tous les tenants et aboutissants de ce truc et qui conclut (je le fait à ma sauce) :
Les problèmes de performance ne sont pas. Les ordinateurs n'arrêtent pas d'accélérer donc pas de pb.
Il faut voir dans ce garbage collector l'ouverture du monde Cocoa et Obj-C à des développeurs potentiels supplémentaires qui auraient pu être rebutés par la gestion mémoire et qui ne le seront plus quand il y aura un garbage collector.
+ de développeurs = + d'applications, + d'innovations et d'idées nouvelles.
J'ai trouvé cette réflexion intéressante et diablement positive. J'adhère.
Bon je laisse les puristes ajouter des précisions/corrections sur ma description approximative de ce qu'est un garbage collector
a+
J'ai entendu plusieurs fois le terme "Garbage Collector" ces derniers temps. Une fois pour "Liger", une fois au boulot sur un script Perl.
J'ai entendu sur ce site que c'était pour les développeurs qui développe avec leurs pieds...
Bref, tout cela a attisé ma curiosité donc je me suis un peu renseigné et je vous livre le fruit de mes recherches.
Un garbage Collector donc, c'est un système qui permet au développeur de s'affranchir de la gestion de la mémoire.
Typiquement, en Objective-C, plus besoin de se préoccuper des alloc/init et des retain/release/autorelease.
Bon, c'est vrai que pour ceux qui se sont penché sur le pb, on peut dire "ouais bon, ca sera plus cool mais pas de quoi fouetter un ....aà¯e..".
D'autres disent que ca impacte les performances lors de l'exécution.
Mais j'ai trouvé un gars qui a l'air de comprendre tous les tenants et aboutissants de ce truc et qui conclut (je le fait à ma sauce) :
Les problèmes de performance ne sont pas. Les ordinateurs n'arrêtent pas d'accélérer donc pas de pb.
Il faut voir dans ce garbage collector l'ouverture du monde Cocoa et Obj-C à des développeurs potentiels supplémentaires qui auraient pu être rebutés par la gestion mémoire et qui ne le seront plus quand il y aura un garbage collector.
+ de développeurs = + d'applications, + d'innovations et d'idées nouvelles.
J'ai trouvé cette réflexion intéressante et diablement positive. J'adhère.
Bon je laisse les puristes ajouter des précisions/corrections sur ma description approximative de ce qu'est un garbage collector
a+
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Ce n'est pas mauvais fondamentalement.
Je fais actuellement beaucoup de Java, et j'avoue que j'apprécie le fait de ne pas me préoccuper de ce que deviennent les objets que je manipule.
Certes, on argue souvent du fait que le garbage-collector est consommateur de ressources lorsqu'il se déclenche. Tout comme on peut répondre qu'avec les perfs montantes des machines, cette consommation tend à devenir négligeable.
Sauf que dans l'esprit du garbage-collector tel que Obj-C semble se diriger, c'est plus pour masquer les "faiblesses" des programmaillons que pour réellement aider la vie du développeur.
Je ne suis pas contre les "aides" qu'apportent certaines technos pour les développeurs, mais cela, à mon avis, entraà®ne la paresse de ce dernier. Avec toutes ces aides, il devient facile de pondre un programme semblant marcher. Mais un programme écrit avec les pieds, reste un mauvais porgramme, c'est à dire quelque chose de plantogène, peu évolutif, et instable dès qu'une version de l'OS change.
Mais bon, après les bindings, pourquoi pas un garbage-collector... C'est l'évolution inévitable !
.
Alors que le GC je suis un peu du même avis que Bru à savoir le risque c'est que les gens du coup ne fassent plus l'effort de comprendre les mécanismes de gestion de la mémoire (alors que c'est un des premiers principes à maà®triser quand on apprend Cocoa, comment bien coder avec les retain/release/..., qui certes ne sont pas évidents quand on commence mais une fois qu'on s'y est mis ça devient naturel) et se laissent aller à la farniente de ne plus rien gérer.
Déjà que quand on "code pas propre" le code est difficile à maintenir mais aussi et surtout source d'erreurs / plantages, alors si on incite les programmeurs à ne plus réfléchir...
Finalement je trouve que ce n'est pas top d'avoir un GC dans la prochaine version de Cocoa.
Déjà que l'autoreleasepool on l'utilise souvent (moi le premier) plus qu'on ne le devrait : à la limite elle ne devrait être utilisée que pour quelques petites variables temporaires et surtout les variables retournées par le fonctions, mais on devrait prendre l'habitude dans des boucles par exemple de faire des vrai releases (et non autorelease) ou créer un autoreleasepool dans la boucle... Et au final on se laisse souvent tenter par la facilité d'utilisation des constructeur de commodité et autorelease... parfois à outrance.
Alors si en plus y'a le GC...