Bon, je relance ici, car le fil est gelé là bas...
>> Le récupérateur de mémoire se déclenche généralement quand il n'y a plus de mémoire disponible, où quand l'application n'a rien de mieux à faire.
Pas d'accord. En gros le GC se déclenche tout le temps : à chaque fois quon quitte la portée d'un objet, il est *immédiatement* récupéré (sauf cas pathologiques pour certains types de GC où la récupération se fait à un autre moment). Quand tu manques de mémoire, c'est l'allocation de plus de mémoire qui se déclenche, pas la récupération.
>> Finalement, un récupérateur de mémoire n'est pas si compliqué que ça. Mais face à quelques «delete» bien placés et pas oubliés, ça fait légèrement lourd.
Un simple GC, c'est simple, oui.
Mais des centaines de « delete » pas forcément bien placés, et parfois oubliés, c'est légèrement relou, face à de simples GC_malloc();
>> PS: Je préfère une application en C qui perd un peu de mémoire sur certaines opérations, à une application java qui consomme 200Mio quoi qu'il arrive.
C'est pas un problème de GC, ni même de langage. C'est un problème de paradigme, et ça n'a rien à voir... Si tu codais orienté objet en C, tu passerais ton temps à créer des objets qui bouffent de la mémoire... En "impératif C", tu crées ce dont tu as besoin, à la main. En POO, tu crées un objet, et immédiatement, toute une hiérarchie d'autres objets dont tu n'as peut-être rien à faire, mais que tu es obligé d'avoir car ils sont liés dans une méthode de la classe virtuelle de l'interface publique du cousin 2.0 de la méthode Cauet(); forcément, ça bouffe plus de mémoire...
Oui, un GC, ça a un coût. Et c'est fouchtrement rentable quand on sait s'en servir. Simplement, ce que tu ne sais (probablement) pas, c'est qu'un GC, c'est pas une solution générique miracle : ça se choisit en fonction du problème à résoudre et des données, puis ça se paramètre en fonction du programme écrit. Le problème, c'est qu'on a souvent un seul GC par langage ou implantation... Le GC devrait être une lib à part.
En fait, un GC est une chose trop importante pour être laissée aux implanteurs d'un langage... C'est aussi un art, tout comme gérer ses free() à la main. À compétences égales de développeur, la version GC est garantie meilleure : un débutant fera mieux avec n'importe quel GC qu'un débutant avec free(), et un pro utilisera son GC dans les meilleures situations, et des free() à d'autres !
[^] # Re: Commentaires aigris
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Faut-il supprimer la tribune ? (suite). Évalué à 3.
>> Le récupérateur de mémoire se déclenche généralement quand il n'y a plus de mémoire disponible, où quand l'application n'a rien de mieux à faire.
Pas d'accord. En gros le GC se déclenche tout le temps : à chaque fois quon quitte la portée d'un objet, il est *immédiatement* récupéré (sauf cas pathologiques pour certains types de GC où la récupération se fait à un autre moment). Quand tu manques de mémoire, c'est l'allocation de plus de mémoire qui se déclenche, pas la récupération.
>> Finalement, un récupérateur de mémoire n'est pas si compliqué que ça. Mais face à quelques «delete» bien placés et pas oubliés, ça fait légèrement lourd.
Un simple GC, c'est simple, oui.
Mais des centaines de « delete » pas forcément bien placés, et parfois oubliés, c'est légèrement relou, face à de simples GC_malloc();
>> PS: Je préfère une application en C qui perd un peu de mémoire sur certaines opérations, à une application java qui consomme 200Mio quoi qu'il arrive.
C'est pas un problème de GC, ni même de langage. C'est un problème de paradigme, et ça n'a rien à voir... Si tu codais orienté objet en C, tu passerais ton temps à créer des objets qui bouffent de la mémoire... En "impératif C", tu crées ce dont tu as besoin, à la main. En POO, tu crées un objet, et immédiatement, toute une hiérarchie d'autres objets dont tu n'as peut-être rien à faire, mais que tu es obligé d'avoir car ils sont liés dans une méthode de la classe virtuelle de l'interface publique du cousin 2.0 de la méthode Cauet(); forcément, ça bouffe plus de mémoire...
Oui, un GC, ça a un coût. Et c'est fouchtrement rentable quand on sait s'en servir. Simplement, ce que tu ne sais (probablement) pas, c'est qu'un GC, c'est pas une solution générique miracle : ça se choisit en fonction du problème à résoudre et des données, puis ça se paramètre en fonction du programme écrit. Le problème, c'est qu'on a souvent un seul GC par langage ou implantation... Le GC devrait être une lib à part.
En fait, un GC est une chose trop importante pour être laissée aux implanteurs d'un langage... C'est aussi un art, tout comme gérer ses free() à la main. À compétences égales de développeur, la version GC est garantie meilleure : un débutant fera mieux avec n'importe quel GC qu'un débutant avec free(), et un pro utilisera son GC dans les meilleures situations, et des free() à d'autres !