Ce que je dis c'est qu'avec un GC, on se retrouve très rapidement avec les mêmes problèmes que pour le C/C++.
Ben non, c'est faux. Avec un GC, tu n'as pas de fuite mémoire obscure parce que tu as oublié un free quelque part, tu n'as pas de crash obscur parce que dans tel cas imprévu il y a un double free, etc.
On se retrouve à devoir faire du tuning très bas niveau
Ah, oui, je vois, c'est pour customiser les enjoliveurs ? :-)
Sérieusement, du "tuning très bas niveau" sur un langage à GC, à part pour une application très exigeante, je ne vois pas.
(sauf si par "tuning très bas niveau" tu veux dire régler la taille maximale du tas)
Et à la fin, très fréquemment, tu te rends compte que le système laggue monstrueusement après quelques heures/jours d'utilisation
C'est qui "tu" ? Parce que personnellement, en Python et son système de GC rudimentaire, ça ne m'est jamais arrivé d'avoir un système qui "laggue monstrueusement" après quelques jours d'utilisation. Ça ne veut pas dire qu'il ne peut pas y avoir de problème, mais par rapport à la corvée que représente la gestion manuelle de la mémoire dans une application non-triviale, y a pas photo.
C'est le choix par défaut
Non, désolé, toujours faux. C'est le choix par défaut si tu veux un GC dans ton programme écrit en C.
Mais pour la majorité des gens, "utiliser un GC" implique "programmer dans un langage à GC natif". Et tes 98 paquets qui dépendent (en première approximation) du GC Boehm, c'est que dalle par rapport au nombre de paquets dépendant de Python, Java, Erlang, Ruby, etc. Rions un peu :
$ apt-rdepends -r python | wc -l
Reading package lists... Done
Building dependency tree
Reading state information... Done
20067
$ apt-rdepends -r libgc1c2 | wc -l
Reading package lists... Done
Building dependency tree
Reading state information... Done
229
[^] # Re: la réponse est évidente
Posté par Antoine . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 3.
Ben non, c'est faux. Avec un GC, tu n'as pas de fuite mémoire obscure parce que tu as oublié un free quelque part, tu n'as pas de crash obscur parce que dans tel cas imprévu il y a un double free, etc.
Ah, oui, je vois, c'est pour customiser les enjoliveurs ? :-)
Sérieusement, du "tuning très bas niveau" sur un langage à GC, à part pour une application très exigeante, je ne vois pas.
(sauf si par "tuning très bas niveau" tu veux dire régler la taille maximale du tas)
C'est qui "tu" ? Parce que personnellement, en Python et son système de GC rudimentaire, ça ne m'est jamais arrivé d'avoir un système qui "laggue monstrueusement" après quelques jours d'utilisation. Ça ne veut pas dire qu'il ne peut pas y avoir de problème, mais par rapport à la corvée que représente la gestion manuelle de la mémoire dans une application non-triviale, y a pas photo.
Non, désolé, toujours faux. C'est le choix par défaut si tu veux un GC dans ton programme écrit en C.
Mais pour la majorité des gens, "utiliser un GC" implique "programmer dans un langage à GC natif". Et tes 98 paquets qui dépendent (en première approximation) du GC Boehm, c'est que dalle par rapport au nombre de paquets dépendant de Python, Java, Erlang, Ruby, etc. Rions un peu :