Discussion :

[poukill]

@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 ?

[Goten]

RAII et son pendant RFID? :')

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

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

[white_tentacle]

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 .

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.

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

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.

[nikko34]

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

[Klaim]

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.

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.

[DesignFirst]

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

[Klaim]

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

[deubelte]

Moi: Contre car

Garbage Collector + C++=Java

[gl]

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.

[poukill]

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 !

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 !

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

[Bluedeep]

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

[screetch]

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.

[gl]

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.

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.

[koala01]

Mauvais développeur, changer de développeur.

Oui, mais... bon...

Je sais que C++ est (considéré comme ) un langage complexe, BLA-BLA, responsabilisant, BLA-BLA, souvent élitiste, (je vais pas vous ressortir tout le discours habituel des opposants à C++) 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

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

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

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

Surtout en C++

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

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"

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

[JolyLoic]

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

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

[yan]

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.

[méphistopheles]

[...]
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à ) 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

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"

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

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

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.

[JolyLoic]

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

[JolyLoic]

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

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