J'en ai déjà parlé un peu plus haut mais la librairie PWLib, utilisée dans OpenH323 ( http://www.openh323.org(...) ), possède un système de gestion de l'allocation des objets qui permet de vérifier et retrouver les mémory-leaks; de plus, je suis tout à fait d'accord sur le fait que si un programme est bien développé, les memory-leaks ne sont pas durs à trouver.
Pour ce qui est de travailler sur de gros projets, les GC sont avantageux sur les petits développements où l'on ne veut pas s'embêter à gérer la mémoire (y'a des malloc en bash?); plus une appli est grosse, plus il est important de bien gérer la mémoire... Quand je vois le temps que met LimeWire à se lancer et à s'arrêter, et quand je vois le paquet de mémoire qu'il libère quand je quitte, je me dis que les marchants de mémoire et de CPU n'ont pas fini de nous parler de la beauté de Java et de l'avantage du GC en général...
[^] # Re: Comment ça marche ?
Posté par pas_moi . En réponse à la dépêche Al Stevens n'aime pas QT. Évalué à 5.
J'en ai déjà parlé un peu plus haut mais la librairie PWLib, utilisée dans OpenH323 ( http://www.openh323.org(...) ), possède un système de gestion de l'allocation des objets qui permet de vérifier et retrouver les mémory-leaks; de plus, je suis tout à fait d'accord sur le fait que si un programme est bien développé, les memory-leaks ne sont pas durs à trouver.
Pour ce qui est de travailler sur de gros projets, les GC sont avantageux sur les petits développements où l'on ne veut pas s'embêter à gérer la mémoire (y'a des malloc en bash?); plus une appli est grosse, plus il est important de bien gérer la mémoire... Quand je vois le temps que met LimeWire à se lancer et à s'arrêter, et quand je vois le paquet de mémoire qu'il libère quand je quitte, je me dis que les marchants de mémoire et de CPU n'ont pas fini de nous parler de la beauté de Java et de l'avantage du GC en général...