Tout de même, tu m'accuses de ne pas être subtil mais tu ne fais pas mieux. Et en plus tu débarques après la fin du trolldi. Bref, c'est pas joli joli tout ça.
Alors dans un premier temps, tu réalises l'exploit de me dire que je n'ai qu'à utiliser un garbage collector pour ne pas avoir à gérer ma mémoire à la main (soit) et de m'expliquer dans le même commentaire que les garbage collector c'est pourri parce que la mémoire n'est jamais désallouée si on met pas les pointeurs à null. Donc au final, il faut que j'utilise un garbage collector mais les garbage collector, ça sert à rien ?
Deuxièmement, certes tu as trouvé une implémentation de garbage collector (GC) en C++ qui a l'air correct mais tu seras bien obligé d'admettre qu'utiliser un GC en C++ n'est pas courant.
Le GC que tu présentes est décrit sur une page de HP labs ce qui laisse clairement penser que ce n'est pas vraiment prêt pour être utilisé en production. Les bibliothèques C++ majeures (boost, Qt) n'incluent pas de GC. Le code de KDE, écrit en majorité en C++ n'utilise pas de GC. Bref, en C++, on gère sa mémoire à la main en pratique. Enfin, on utilise pas malloc en C++ mais new.
Troisièmement, dans la deuxième partie de ton message, tu m'expliques que Java va consommer plus de RAM (je vais expliquer dans la suite dans mon message pourquoi ton explication est fausse) puis tu utilises cet argument pour dire que les « performances sont dramatiquement plus basses ». Tu mélanges tout. Un programme peut consommer beaucoup de RAM s’exécuter rapidement, il ne faut pas confondre rapidité d'exécution et consommation mémoire.
Dernièrement, l'explication que tu donnes du fonctionnement d'un garbage collector est complètement erronée. Certes la JVM alloue un pool de mémoire à son démarrage, ce qui est une bonne idée pour de questions de performance, sa taille est réglable via le paramètre -Xms. Ce que tu ne précises pas est que la taille de ce pool est dynamique : il grandit si le programme a besoin de plus de mémoire (on ne fait pas qu'incrémenter le pointeur) et rétrécit (la mémoire est désallouée) si le programme à besoin de moins de RAM. La JVM ne fait pas qu'incrémenter un pointeur vers le pool, elle gère aussi sa taille.
Et évidemment, il n'y pas besoin de mettre des pointeurs à null pour que les objets vers lequels ils pointent soient désalloués, le GC désalloue les objets hors de portée (les choses invisibles sont détruites...) sans que les pointeurs soient mis à null (voir comptage de référence, et mark and sweep sur Garbage collection)
Et pour information, Hadoop (un environnement de programmation distribuée adapté au traitement de données volumineuses, le fameux big data) est écrit en Java et tourne sur 42000 serveurs chez Yahoo!. Si Java ne permettait de faire des daemons performants, tu crois pas qu'ils auraient recodé Hadoop en C++ ?
Bref, remballe ton troll bas de gamme, il est trop facile à démonter.
[^] # Re: la réponse est évidente
Posté par X345 . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 7.
Tout de même, tu m'accuses de ne pas être subtil mais tu ne fais pas mieux. Et en plus tu débarques après la fin du trolldi. Bref, c'est pas joli joli tout ça.
Alors dans un premier temps, tu réalises l'exploit de me dire que je n'ai qu'à utiliser un garbage collector pour ne pas avoir à gérer ma mémoire à la main (soit) et de m'expliquer dans le même commentaire que les garbage collector c'est pourri parce que la mémoire n'est jamais désallouée si on met pas les pointeurs à null. Donc au final, il faut que j'utilise un garbage collector mais les garbage collector, ça sert à rien ?
Deuxièmement, certes tu as trouvé une implémentation de garbage collector (GC) en C++ qui a l'air correct mais tu seras bien obligé d'admettre qu'utiliser un GC en C++ n'est pas courant.
Le GC que tu présentes est décrit sur une page de HP labs ce qui laisse clairement penser que ce n'est pas vraiment prêt pour être utilisé en production. Les bibliothèques C++ majeures (boost, Qt) n'incluent pas de GC. Le code de KDE, écrit en majorité en C++ n'utilise pas de GC. Bref, en C++, on gère sa mémoire à la main en pratique. Enfin, on utilise pas
mallocen C++ maisnew.Troisièmement, dans la deuxième partie de ton message, tu m'expliques que Java va consommer plus de RAM (je vais expliquer dans la suite dans mon message pourquoi ton explication est fausse) puis tu utilises cet argument pour dire que les « performances sont dramatiquement plus basses ». Tu mélanges tout. Un programme peut consommer beaucoup de RAM s’exécuter rapidement, il ne faut pas confondre rapidité d'exécution et consommation mémoire.
Dernièrement, l'explication que tu donnes du fonctionnement d'un garbage collector est complètement erronée. Certes la JVM alloue un pool de mémoire à son démarrage, ce qui est une bonne idée pour de questions de performance, sa taille est réglable via le paramètre -Xms. Ce que tu ne précises pas est que la taille de ce pool est dynamique : il grandit si le programme a besoin de plus de mémoire (on ne fait pas qu'incrémenter le pointeur) et rétrécit (la mémoire est désallouée) si le programme à besoin de moins de RAM. La JVM ne fait pas qu'incrémenter un pointeur vers le pool, elle gère aussi sa taille.
Et évidemment, il n'y pas besoin de mettre des pointeurs à null pour que les objets vers lequels ils pointent soient désalloués, le GC désalloue les objets hors de portée (les choses invisibles sont détruites...) sans que les pointeurs soient mis à null (voir comptage de référence, et mark and sweep sur Garbage collection)
Et pour information, Hadoop (un environnement de programmation distribuée adapté au traitement de données volumineuses, le fameux big data) est écrit en Java et tourne sur 42000 serveurs chez Yahoo!. Si Java ne permettait de faire des daemons performants, tu crois pas qu'ils auraient recodé Hadoop en C++ ?
Bref, remballe ton troll bas de gamme, il est trop facile à démonter.