Garbage collector en C++, pour ou contre ?

Citation:

---

Envoyé par yan

@koala01 j'avais bien compris ;) je voulais juste dire que quand je parle de RAII je pense aux pointeurs intelligents, std::vector, flux,... qui libèrent leurs ressources lors de leurs destruction à la sortie de leurs scope.

---

Faudrait quand même un jour trouver un nom pour ça. ;)
Quand on veut dire : "Gestion intelligente de la mémoire à base de classes dédiées et/ou de pointeurs intelligents, le tout étant exeption safe à garantie basique au minimum", on dit : RAII.
Et là RAII, c'est plus le bon terme. Il vaut mieux RFID, c'est plus représentatif. Mais c'est pas suffisant pour parler de cette gestion globale des ressources.

Que doit-on dire à la fin, pour tout que tout le monde se comprenne sans avoir à faire de digressions ? :aie:

RAII et son pendant RFID? :')

Concernant l'utilisation pratique d'un GC, je pense que là ou il serait vraiment très interessant serait lors de phases de prototypages. Quand on veut se concentrer sur le résultat de ce qu'on veut construire pour voir comment ça marche, experimenter, et ne pas être frêné par une reflexion avancée de la gestion de la mémoire est vraiment très très utile. (dans les cas ou une gestion précise de la mémoire n'apporte rien a ce qu'on veut prototyper)

On pourrait argumenter qu'utiliser des smart pointers serait tout aussi efficace mais la pratique montre que ça reste moins facile a manipuler qu'un gc dans d'autres languages (qui s'articulent autour certes mais restent largement plus rapides a utiliser pour du prototypage). (Ce qui fait d'ailleurs qu'un GC en c++ ne vaudrait pas le coup si il n'était pas "plus evident" a utiliser que des pointeurs intelligents).

Personellement cela m'ennuie d'avoir a passer a un autre language juste pour vérifier qu'un mécanisme simple de gameplay puisse marcher. Je préfère rester en C++ mais cela m'ennuie aussi d'avoir a faire attention a l'organisation de la mémoire alors que ce n'est pas du tout le point important du prototypage. Je préfère m'y consacrer quand je repasse en mode développement "normal", pas "jetable".
(peut être qu'il n'y a que pour les jeux qu'on a besoin de prototyper rapidement?)

Sinon, je ne suis pas au fait des détails des réunions du commité, mais est-ce qu'on sait si l'idée serait d'avoir une logique définie par le standard pour un garbage collector, ou bien plutot un ensemble de principe et "d'interface" qui permettent au fournisseurs de compilateurs de proposer plusieurs types d'implémentations?
Parceque ça ça serait chouette : choisir le comportement du garbage collector.
Si il y a un comportement au moins garanti de base par le standard, ça permettrait d'avoir un GC portable et en même temps lapossibilité d'utiliser un GC spécialisé quand c'est nécessaire (de la même façon qu'on spécialiserai new/delete sous certaines contraintes hardware par exemple).

Citation:

---

Envoyé par Klaim

Concernant l'utilisation pratique d'un GC, je pense que là ou il serait vraiment très interessant serait lors de phases de prototypages. Quand on veut se concentrer sur le résultat de ce qu'on veut construire pour voir comment ça marche, experimenter, et ne pas être frêné par une reflexion avancée de la gestion de la mémoire est vraiment très très utile. (dans les cas ou une gestion précise de la mémoire n'apporte rien a ce qu'on veut prototyper)

---

Mon expérience est qu'un prototype finit toujours en production, et que donc, c'est une mauvaise idée de faire des prototypes à l'arrache :).

Citation:

---

On pourrait argumenter qu'utiliser des smart pointers serait tout aussi efficace mais la pratique montre que ça reste moins facile a manipuler qu'un gc dans d'autres languages (qui s'articulent autour certes mais restent largement plus rapides a utiliser pour du prototypage). (Ce qui fait d'ailleurs qu'un GC en c++ ne vaudrait pas le coup si il n'était pas "plus evident" a utiliser que des pointeurs intelligents).

---

Le problème ne se pose pas en terme de gc/smart pointer/je ne sais quoi, mais avant tout de responsabilité et du type de la ressource. Si je peux trouver un responsable à ma ressource, le GC est inutile. Si j'ai une responsabilité partagée est que ma ressource est de la mémoire, le GC est une approche clairement défendable. Si c'est autre chose que de la mémoire, pas le choix, va falloir utiliser intelligemment les smart_pointers, ou revoir le design.

Citation:

---

Personnellement cela m'ennuie d'avoir a passer a un autre langage juste pour vérifier qu'un mécanisme simple de gameplay puisse marcher. Je préfère rester en C++ mais cela m'ennuie aussi d'avoir a faire attention a l'organisation de la mémoire alors que ce n'est pas du tout le point important du prototypage. Je préfère m'y consacrer quand je repasse en mode développement "normal", pas "jetable".
(peut être qu'il n'y a que pour les jeux qu'on a besoin de prototyper rapidement?)

---

Beaucoup de gens utilisent python pour du prototypage rapide, puis c++ derrière. Je ne crois cependant pas que ce soit lié au GC, mais plutôt à une question de différence de niveau dans les langages (il est plus facile d'être productif en python qu'en c++).

Citation:

---

Sinon, je ne suis pas au fait des détails des réunions du commité, mais est-ce qu'on sait si l'idée serait d'avoir une logique définie par le standard pour un garbage collector, ou bien plutot un ensemble de principe et "d'interface" qui permettent au fournisseurs de compilateurs de proposer plusieurs types d'implémentations?
Parceque ça ça serait chouette : choisir le comportement du garbage collector.
Si il y a un comportement au moins garanti de base par le standard, ça permettrait d'avoir un GC portable et en même temps lapossibilité d'utiliser un GC spécialisé quand c'est nécessaire (de la même façon qu'on spécialiserai new/delete sous certaines contraintes hardware par exemple).

---

Vu que le GC, c'est avant tout un allocateur, j'imagine extrêmement mal le comité forcer la méthode d'allocation.

il faut aussi voir qu'on est pas sensé utiliser des pointeurs à tout bout de champ sauf si on en a vraiment l'utilité.

Utiliser le code de prototype en production est une mauvaise pratique qui n'a rien a voir avec le fait qu'un prototype reste du code jetable. Personellement j'ai toujours jeté le code prototypé, ou alors tout réécrit ce qui revient au même.

Citation:

---

Beaucoup de gens utilisent python pour du prototypage rapide, puis c++ derrière. Je ne crois cependant pas que ce soit lié au GC, mais plutôt à une question de différence de niveau dans les langages (il est plus facile d'être productif en python qu'en c++).

---

Justement, n'est-ce pas s'isoler exclusivement au haut niveau d'abstraction du code que de laisser faire un systeme automatique de gestion de la mémoire/des resources?

Pour le prototypage, se concentrer sur le haut niveau est essentiel (sauf si c'est un prototype "technique" evidemment) et c'est là ou je vois bien l'interet.

Comme dit, passer au python et donc globalement a un environnement radicalement différent m'ennuie, notemment lorsque je ne peut pas utiliser les même bibliothèques pour le prototype et l'application finale.

Ce débat de GC a pas mal d'années derrière lui , et a chaque fois on trouve des pour et des contres a l'introduction de GC dans C++, et je pense que l'autre débat qui est fortement lié a celui la est quand utiliser C++?

dans les années 90 il y avait pas mal de projets développés entièrement en C++ (IHM,Metier,Database,Distribué) et la effectivement on peut se poser la question sur la non existence de la GC, puisque normalement le but est de se concentrer le métier et non sur les aspects de la couche technique, donc gérer la mémoire pour n'importe quel module peut être très pénalisant, il y a pas mal de modules ou la rapidité n'est pas la priorité donc utiliser un GC sera très favorable même si ca peut nuire a la rapidité.

mais actuellement d'autres langages ont vu le jour et chacun a ses points forts et faibles, et on a pas malheureusement inventer le langage parfait adapté a tout les besoins, donc logiquement on va choisir le bon langage adapté a chaque besoin, et C++ peut être utilisé que pour les modules ou une rapidité et une bonne gestion mémoire sont exigées, et dans ce cas on aura pas besoin de GC puisqu'il faut bien maitriser la libération mémoire.

donc a mon avis ce débat aurai plus de sens il y a des années mais maintenant l'utilisation même de C++ pour les nouveaux dev est très limité a ce que c'est bien faire C++, et donc pas besoin de la GC.

peut etre il y 'en a pas mal de developpeurs C++ qui vont dire qu'avec C++ on peut tout faire, certes oui mais il y a pas mal de facteurs qui font que les sociétés choisissent d'utiliser de moins en moins C++, mais la c'est un autre debat qui n'a pas de fin :)

Citation:

---

donc a mon avis ce débat aurai plus de sens il y a des années mais maintenant l'utilisation même de C++ pour les nouveaux dev est très limité a ce que c'est bien faire C++, et donc pas besoin de la GC.

---

Je ne suis que partiellement d'accord, a cause du principe des prototypes comme je le disais précédemment.
J'ai déjà prototypé dans un language à GC, c'est rapide, mais ça pose des tas de problèmes lorsqu'on veut voir si tel ou tel technologies dispo uniquement en C++ (souvent des libs très spécifiques) sont adéquates ou tiennent le coup.
Du coup dans ces cas là, on preferera directement utiliser le même language pour le prototype et pour l'application finale. Je vois l'utilité dans le GC principalement là.

Moi: Contre car

Garbage Collector + C++=Java

Citation:

---

Envoyé par deubelte

Garbage Collector + C++=Java

---

Le Garbage Collector est loin d'être la seule différence entre Java et C++.
En outre si un jour un Garbage Collector est ajouté en standard en C++, les mécanismes existant continueront d'exister, ne serait-ce que pour conserver la compatibilité avec l'existant.

Deux points :
1 - Pour moi le C++ est effectivement synonyme de performances, donc a sa place dans des applications où la performance est vraiment requise...
Le GC impacte forcément un peu les performances, en terme de place mémoire et de temps d'exécution. Après je n'ai aucunes idées des couts réels de perf, ça c'est un débat d'implémentation de GC et de spécialistes ! :aie:

2 - Les applications qui nécessite la performance sont assez nombreuses.La puissance des machines devient de plus en plus forte, et la plupart des langages en profitent pour avoir un temps d'exécution plus lent mais un temps de développement raccourcit. Du coup les applications ne vont pas plus vite avec l'augmentation de la puissance des PCs.
J'ai déjà vu des labos intégrer des technos java dans des applis temps-réel embarqué. C'est plus lent, mais plus rapide à développer ! 8O

Moi je pense que le développement "efficace" a encore de beaux jours devant lui ! ;)

Citation:

---

Envoyé par DesignFirst

peut etre il y 'en a pas mal de developpeurs C++ qui vont dire qu'avec C++ on peut tout faire,

---

C'est vrai aussi pour l'assembleur :D

je dirai contre, après avoir mûrement reflechi au problème.
Le côté pour: on est pas obligé de s'en servir, c'est optionnel, et si l'on peut choisir, après tout, je ne cherche pas a savoir quelle lessive utilise mon voisin.

Le côté contre: il va falloir défendre son bifteck maintenant, et ca ca me broute. Je vais devoir expliquer a des développeurs que le GC n'est pas magique, que si tu fais du caca, ca ne va pas magiquement marcher. Ca va donner un argument a debattre de plus au moment ou l'on démarre un projet (On a le droit aux templates? on utilise des tabs ou des espaces? caml case ou notation hongroise? GC ou pas?)
c'est aussi une excellente occasion de permettre aux gens de se déresponsabiliser de connaître les propriétaires des objets, vu que le GC s'en occupe, de finir avec une soupe immangeable et que personne ne sache comment ce plat de spaghetti se démêle. C'est dangereux...

Lorsque je développe j'utilise le RAII et je teste régulièrement que l'application que je développe n'a pas laissé une seule allocation mémoire a la sortie du programe. Je n'ai pas eu a corriger de leak mémoire depuis plus de deux ans et je ne n'ai pas eu besoin d'un GC pour m'y aider, donc perso je trouve ca superflu.

Citation:

---

Envoyé par screetch

Le côté contre: il va falloir défendre son bifteck maintenant, et ca ca me broute. Je vais devoir expliquer a des développeurs que le GC n'est pas magique, que si tu fais du caca, ca ne va pas magiquement marcher. Ca va donner un argument a debattre de plus au moment ou l'on démarre un projet (On a le droit aux templates? on utilise des tabs ou des espaces? caml case ou notation hongroise? GC ou pas?)
c'est aussi une excellente occasion de permettre aux gens de se déresponsabiliser de connaître les propriétaires des objets, vu que le GC s'en occupe, de finir avec une soupe immangeable et que personne ne sache comment ce plat de spaghetti se démêle. C'est dangereux...

---

Mauvais développeur, changer de développeur.

Plus sérieusement, cet argument, que je comprends, ne me convainc pas vraiment.
Si on commence à enlever tout ce qui risque d'être mal utilisé, il ne va pas rester grand chose.

Citation:

---

Envoyé par screetch

Je n'ai pas eu a corriger de leak mémoire depuis plus de deux ans et je ne n'ai pas eu besoin d'un GC pour m'y aider, donc perso je trouve ca superflu.

---

Un GC ne résout pas par miracle toutes les fuites mémoires (bien que dans certains cas, cela puisse aider). Et présente d'autres intérêts.

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).

Bref un outil comme un autre avec ces avantages et ces inconvénients. Ni plus, ni moins.

Citation:

---

Envoyé par gl

Mauvais développeur, changer de développeur.

---

Oui, mais... bon...

Je sais que C++ est (considéré comme :question:) un langage complexe, BLA-BLA, responsabilisant, BLA-BLA, souvent élitiste, (je vais pas vous ressortir tout le discours habituel des opposants à C++:D) mais quand même aie:

Je ne me plains absolument pas de ce coté plutôt responsabilisateur ni de son coté vaguement élitiste, loin de là, mais..

S'il est vrai que l'on peut avoir du très bon comme du très mauvais en C++, j'ai envie de jouer à l'avocat du diable en disant que le résultat sera très fortement influencé par la qualité du développeur.

Et il faut reconnaitre que les *bons* développeurs ne sont pas forcément légions :aie:

Le risque est souvent relativement élevé de virer un mauvais développeur C++ pour le remplacer par... un développeur encore pire :aie:

Ce risque, pour présent qu'il puisse être avec les langages garbage collecté me semble moins critique quand même, non :question:

Citation:

---

Si on commence à enlever tout ce qui risque d'être mal utilisé, il ne va pas rester grand chose.

---

Surtout en C++ :aie:

Citation:

---

Un GC ne résout pas par miracle toutes les fuites mémoires (bien que dans certains cas, cela puisse aider). Et présente d'autres intérêts.

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).

Bref un outil comme un autre avec ces avantages et ces inconvénients. Ni plus, ni moins.

---

Tout à fait... Sauf que...

Quand on voit les murs à franchir pour faire évoluer la mentalité de certains développeurs et la "loi du moindre effort" qui domine souvent chez eux, je ne peux m'empêcher (je ne fais plus l'avocat du diable là :D) de me demander quel impact l'introduction d'un tel outil aura chez eux.

Ne risquent-ils pas de se reposer, purement et simplement, sur la présence du GC sans même se poser la question de savoir s'il est ne serait-ce que opportun de ne pas le désactiver :question:

Ne risque-t-on pas d'avoir des réflexions du genre de "peut-être que je pourrais améliorer certains aspects en m'en passant, mais je préfère l'utiliser quand même" :question:

Je ne suis pas formellement opposé à ce qu'on introduise un GC dans C++, mais ce qui m'inquiète énormément, ce sont les dérives qu'une telle introduction pourrait générer auprès de certains.

A choisir, je me demande si je préfèrerais encore passer mon temps à "former" les développeurs pour leur apprendre comment s'en passer :aie:

Citation:

---

Envoyé par koala01

A choisir, je me demande si je préfèrerais encore passer mon temps à "former" les développeurs pour leur apprendre comment s'en passer :aie:

---

Je pense que cette formation serait absolument nécessaire quoi qu'il arrive. J'ai du mal à envisager un vrai programme en C++ où le GC serait la bonne solution partout. Il n'évitera donc pas de devoir maîtriser les autres techniques, ne serait-ce que pour gérer les classes possédant une ressource autre que de la mémoire.

Il éviterait seulement de devoir effectuer à chaque fois le travail de réflexion et de codage lié à la mise en œuvre des autres techniques, quand ce travail n'apporte rien. Je le vois comme un gain de temps à l'utilisation, mais pas à l'apprentissage.

Et je ne suis pas certain, pour répondre à Klaim, qu'il soit opportun de le cantonner par exemple au prototypage (même s'il a là de l'intérêt aussi). Déjà, tous les aspects d'un code, même en production, ne sont pas critiques en performance, et ensuite, il y a des cas où un GC est plus performant que les alternatives...

Ils ont bien ajoutés un GC avec C++/CLI non?
En C#, il me semble que les classes sont exploitées par le GC et les struct comme en C++.

Es ce que cela as tout compliqué?
Je parle de cela pour comparai avec ce qui existe et réfléchir si l'impacte serait si important.

Citation:

---

Envoyé par koala01

[...]
Quand on voit les murs à franchir pour faire évoluer la mentalité de certains développeurs et la "loi du moindre effort" qui domine souvent chez eux, je ne peux m'empêcher (je ne fais plus l'avocat du diable là :D) de me demander quel impact l'introduction d'un tel outil aura chez eux.

Ne risquent-ils pas de se reposer, purement et simplement, sur la présence du GC sans même se poser la question de savoir s'il est ne serait-ce que opportun de ne pas le désactiver :question:

Ne risque-t-on pas d'avoir des réflexions du genre de "peut-être que je pourrais améliorer certains aspects en m'en passant, mais je préfère l'utiliser quand même" :question:

Je ne suis pas formellement opposé à ce qu'on introduise un GC dans C++, mais ce qui m'inquiète énormément, ce sont les dérives qu'une telle introduction pourrait générer auprès de certains.

A choisir, je me demande si je préfèrerais encore passer mon temps à "former" les développeurs pour leur apprendre comment s'en passer :aie:

---

Tâche qui risque d'être ardue.
J'ai dû récemment (malgré moi) me mettre au C#. Il est vrai que le langage est différent puisque la gestion de la mémoire (manuelle s'entend) n'est pas partie intégrante du langage et n'est plutôt accessible qu'au travers d'une interface étant considérée comme des fonctions avancées du langage (ie: pas les trucs qu'on va apprendre de base).
Or après quelques heures de code, je me suis aperçu que les mauvaises habitudes de mes débuts en C++ revenaient au grand galop: objets partageant leurs membres en public, pléthore d'allocations sans prendre garde à la portée, fonctions monolithiques (mais là, c'est plus dû au fait que tout est dans la déclaration de la classe)...
Je m'en suis aperçu et ai corrigé cela, mais j'ai l'impression que plus on a de facilités... moins on fait attention à la lisibilité ou à l'efficacité du code...Ce qui dans le cas des langages interprétés n'est en général pas trop grave car la performance n'est pas le but principal, mais risque tout de même de ralentir significativement l'application avec l'accumulation de ce genre de pratiques...
Pour revenir au C++, ce qui m'inquiète, c'est qu'en plus de la réputation d'être long à développer et facilement bugué , les mauvais développeurs ajoutent cette fois au C++ la réputation d'être lent... ce qui pour le coup lui serait à mon avis fatal :( (du moins auprès des boites non spécialisées).

Citation:

---

Envoyé par JolyLoic

Je pense que cette formation serait absolument nécessaire quoi qu'il arrive. J'ai du mal à envisager un vrai programme en C++ où le GC serait la bonne solution partout. Il n'évitera donc pas de devoir maîtriser les autres techniques, ne serait-ce que pour gérer les classes possédant une ressource autre que de la mémoire.

Il éviterait seulement de devoir effectuer à chaque fois le travail de réflexion et de codage lié à la mise en œuvre des autres techniques, quand ce travail n'apporte rien. Je le vois comme un gain de temps à l'utilisation, mais pas à l'apprentissage.

---

C'est bien le problème :s et c'est probablement pour cela qu'il serait beaucoup mieux en tant qu'option de compilation (en général pas trop accessible au débutants) voire mieux: en tant que bibliothèque NON standard (voire une combinaison des deux) plutôt que dans la norme directement.

Citation:

---

Envoyé par méphistopheles

C'est bien le problème :s et c'est probablement pour cela qu'il serait beaucoup mieux en tant qu'option de compilation (en général pas trop accessible au débutants) voire mieux: en tant que bibliothèque NON standard (voire une combinaison des deux) plutôt que dans la norme directement.

---

Un telle bibliothèque existe déjà, mais ce n'est pas une bonne solution. Déjà, il y a légèrement besoin d'un support minimal du langage pour ça (et ce support devrait être là en C++0x, je dis devrais car je ne suis pas certain que le support minimum qui y sera est vraiment le bon). Et surtout, si j'utilise dans mon programme la bibliothèque A qui tire la bibliothèque de gc GC1, et B qui tire la bibliothèque de gc GC2, je me retrouve avec 2 GC dans mon programme, ça va être un sacré boxon...

Citation:

---

Envoyé par yan

Ils ont bien ajoutés un GC avec C++/CLI non?

---

Sauf que C++/CLI n'est pas vraiment un langage, mais deux langages différent qui cohabitent dans un même code source...

Citation:

---

Envoyé par yan

En C#, il me semble que les classes sont exploitées par le GC et les struct comme en C++.

---

Pas vraiment... Les value types (struct) sont très limités dans ce qu'on peut faire avec par rapport aux types du C++.

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...