Garbage collector en C++, pour ou contre ?

Citation:

---

Il est toujours possible de ne pas avoir de fuite mémoire sans GC, mais dans certains cas, un GC est probablement la solution la plus simple à mettre en œuvre (graphe).

---

C'est un argument que je n'aime pas. Si le GC est le seul a même de résoudre ce genre de problème (ou s'il est la solution la plus simple) cela peut être une bonne indication que les liens entre les objets sont trop complexex.
Je le concois parfaitement pour l'ecriture d'un langage de script par exemple (ou l'on est pas responsable du graphe d'objet des scripts, ou bien on ne publie pas assez d'information pour laisser au scripteur le choix d'une référence forte ou faible, etc). Mais si on l'utilise parce que l'on a soi meme ecrit une soupe imbuvable, ca me semble pas un usage correct.

Citation:

---

Envoyé par screetch

C'est un argument que je n'aime pas. Si le GC est le seul a même de résoudre ce genre de problème (ou s'il est la solution la plus simple) cela peut être une bonne indication que les liens entre les objets sont trop complexex.

---

J'ai cru comprendre que le GC est plus adapté quand on créé beaucoup de petit objet dans un temps très court. Par exemple, sur du gros traitement de texte, il est plus rentable de déléguer la destruction de la mémoire. Car sinon on arrête pas de faire de la désallocation.
Après je dit peut être une connerie...

Par rapport à l'histoire du graph, l'intérêt est peut être la lisibilité du code? Ça évite d'avoir des shared_ptr/weak_ptr à tous va qui pourrai polluer la lisibilité, non?

Citation:

---

Envoyé par yan

J'ai cru comprendre que le GC est plus adapté quand on créé beaucoup de petit objet dans un temps très court. Par exemple, sur du gros traitement de texte, il est plus rentable de déléguer la destruction de la mémoire. Car sinon on arrête pas de faire de la désallocation.
Après je dit peut être une connerie...

---

C'est bien ce qui est couramment admis. Les GCs limitent de fait la fragmentation mémoire.

Citation:

---

Par rapport à l'histoire du graph, l'intérêt est peut être la lisibilité du code? Ça évite d'avoir des shared_ptr/weak_ptr à tous va qui pourrai polluer la lisibilité, non?

---

Le problème est plutôt que parfois, il n'y a pas clairement de responsable pour chaque objet, que la complexité des liens entre les objets est intrinsèque au problème lui-même. Si résoudre toutes ces contraintes revient pratiquement à écrire un garbage collector, autant que le langage m'en offre un, il sera très probablement de meilleure qualité.

un pool mémoire pourrait être plus efficace qu'un GC pour les petits objets non?

JolyLoic> Je ne pense pas non plus qu'un GC soit utile uniquement en prototypage, mais plutot que c'est là où je vois un gros interet, en terme de développement et non de maintenance.

L'autre point effectivement c'est pour gérer un certain type d'objets ou plusieurs types dont on préfère la logique d'un GC plutot que le déterminisme classique du RAII.
Dans ce cas le GC éviterai d'avoir a se farcir les manipulations liées à un pool.

edit> En fait, il faudrait un nouveau "new" mais pour indiquer que l'objet est garbage collecté, et du coup ça ne serait pas vraiment un pointeur qu'on récupérerais?

Citation:

---

Envoyé par screetch

C'est un argument que je n'aime pas. Si le GC est le seul a même de résoudre ce genre de problème (ou s'il est la solution la plus simple) cela peut être une bonne indication que les liens entre les objets sont trop complexex.

---

De ce que j'ai compris, c'est plutot parcequ'on considère qu'on aura pas assez de temps pour vraiment résoudre le problème et qu'on préfère avoir une solution qui marche immédiatement plutot qu'une solution parfaite plus tard qui rends le GC interessant. Donc surtout utile dans un cas d'impasse a cause des deadlines, pas seulement a cause de la techique.

Citation:

---

Envoyé par screetch

C'est un argument que je n'aime pas. Si le GC est le seul a même de résoudre ce genre de problème (ou s'il est la solution la plus simple) cela peut être une bonne indication que les liens entre les objets sont trop complexe.

---

La présence de nombreux cycles peut être intrinsèque à ce que l'on modélise, par exemple un réseau (qu'il soit informatique, routier, ferroviaire ou autre), et à moins de changer les données du problème, il faut bien gérer ces cycles.

Il existe plusieurs solutions pour gérer la mémoire dans ce cas (utilisation conjointe de shared_ptr/weak_ptr, responsabilité de la durée de vie en dehors de la structure du graphe, représentation du graphe par matrice ou liste d'adjacence, etc.), le garbage collector est un de ses moyens qui est simple à mettre en place et parfois largement suffisant pour ce que l'on souhaite faire.
Lorsqu'un mécanisme satisfait à nos besoins, je ne vois pas l'intérêt de mettre en place quelque chose de plus complexe qui n'amène pas un gain utile.

Citation:

---

Envoyé par Klaim

De ce que j'ai compris, c'est plutôt parce-qu'on considère qu'on aura pas assez de temps pour vraiment résoudre le problème et qu'on préfère avoir une solution qui marche immédiatement plutôt qu'une solution parfaite plus tard qui rends le GC intéressant. Donc surtout utile dans un cas d'impasse a cause des deadlines, pas seulement a cause de la technique.

---

Absolument pas, l'utilisation d'un GC n'est pas une solution "quick and dirty" pour contourner un problème qu'on résoudra vraiment plus tard.

Le GC est une vrai solution tout a fait satisfaisante dans certains cas (mais certainement pas dans tous).

Justement n'y a t'il pas un risque de voir naitre une nouvelle école qui laissera toute la gestion de mémoire au GC (par simplicité, par fainéantise, parce que l'évolution du langage le permet, parce que la tendance actuelle est au managé, ...) et les résistants (l'école moderne actuelle - nous) qui ne l'utiliserons qu'avec parcimonie ?
ça rejoint ce que disait Screetch sur le bifteck à défendre et le danger c'est que ces deux écoles ne puissent plus communiquer entre elles.

Donc je n'ai pas d'avis définitif sur la question. Je sais juste que j'ai réussi à m'en passer jusqu'à présent mais si ce fût au prix de torticolis à base de SmartPtr et que, pour ce cas là, un GC m'aurait soulagé.

En fait souvent pour les features de ce genre ou tout dépends finalement du choix du programmeur, la plupart du temps le commité semble préférer donner le choix que d'imposer un choix. Du coup est-ce que cette question aura un quelconque poids au final?

Citation:

---

Envoyé par gl

le garbage collector est un de ses moyens qui est simple à mettre en place et parfois largement suffisant pour ce que l'on souhaite faire.
Lorsqu'un mécanisme satisfait à nos besoins, je ne vois pas l'intérêt de mettre en place quelque chose de plus complexe qui n'amène pas un gain utile.

---

mais je pense qu'il est un peu plus que "suffisant", c'est comme pour l'allocation de petits objets: le GC a d'autres effets qui ne sont pas forcément ceux dont tu as besoin, et qui vont entraîner de multiples conséquences sur le programme.
Une solution a base de shared_ptr/gestion de vie externalisée a au moins l'avantage de ne pas "contaminer" (bon c'est un peu negatif comme mot) le reste du programme

Citation:

---

Envoyé par Klaim

En fait souvent pour les features de ce genre ou tout dépends finalement du choix du programmeur, la plupart du temps le commité semble préférer donner le choix que d'imposer un choix. Du coup est-ce que cette question aura un quelconque poids au final?

---

du programmeur? quand il n'y en a qu'un, oui ca va. C'est quand il y en a beaucoup que ca pose des problèmes. (héhé)

comme j'ai dit plus haut, au demarrage d'un projet il faudra décider de ce que l'on va utiliser, ce sera un autre débat (eternel) entre les pro- et les con-gc
un peu comme ceux qui disent qu'il faut mettre des tabulations et ceux qui disent que non, les espaces c'est mieux.
un peu comme ceux qui disent que OpenGL c'est vachement mieux que directx, mais non andouille c'est directx le mieux.

prenons un exemple: dans notre equipe, le programme principal est fait en C++ très efficace, il ne viendrait a l'idée de personne de coller un garbage collector dedans. Le programme est testé et bien stable, pas de leak memoire, et on a besoin d'un minimum de temps réel. Il n'y aurait pas débat.
Pour les outils qui gravitent autour, chacun choisirait par simplicité d'utiliser un GC, notre éditeur qui est déjà le point le plus faible de notre offre logicielle aurait sans doute droit au GC (s'il n'était pas deja ecrit en C#, c'est une situation hypothétique). Et pourquoi? "parce que c'est l'éditeur", on a pas envie de se coltiner la résponsabilité des objets, on s'en fout si ca leak un peu, si c'est un poil plus lent, etc.
Le résultat c'est un éditeur qui n'est déjà pas aujourd'hui a hauteur du logiciel principal, pas _du tout_. Parce que les gens se déresponsabilisent de l'outil, parce que personne n'a envie de travailler dessus ou de les maintenir a jour.
Je ne sais pas si le GC serait pour l'éditeur une bénediction ou une malédiction. Mais pour l'équipe, c'est une trop belle occasion de se débarasser d'un problème, et en général quand ca arrive, quelqu'un paye pour ce manque de responsabilité plus tard.

J'ai l'impression qu'on est à peu près tous d'accord que le GC c'est bien et c'est probablement utile, mais que le problème est celui de son utilisation et surtout celui de l'"addiction" des développeur qu'il pourrait développer :?...
C'est donc plus un problème humain que logiciel: dans l'hypothèse d'une communauté de développeurs pure et parfaite (:roll:) le GC semble avoir sa place en tant qu'outil. Le problème semble être que dans le monde réel, le GC risque d'entrainer des fuites de mémoire de programmeurs... ou plutot, le déficit de formation (beaucoups d'étudiants "formés" au C++ (ou plutot au C with classes) n'entendent déjà jamais parler de RAII. Une partie y vient par-ce qu'il se coltinent des problèmes de mémoire), la présence d'un GC ne peut que faire empirer cela.

Je ne connais pas quelle est la proportion de "bons" développeurs C++, mais si une bonne partie de la communauté sortant de formation fait un code GC dépendant, je ne vois pas pourquoi les chefs d'entreprise continueraient à investir dans le développement de programmes plus onéreux (en temps) pour un résultat similaire en termes de performances.

Bref, Une fois de plus, ce sont plus les effets de bords du GC qui sont au centre du débat que le GC lui-même qui me semble être un bon outil de développement...