Discussion :

[adiGuba]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

null

suffit, pas besoin d'un autre mot-clef ! S'il n'y a plus de référence, l'espace pris par l'objet pourra être libéré. S'il y en a encore, il n'est pas libérable puisque utilisé.

Je me suis mal exprimé dans ce message qui date de plus de deux ans

Je répondais à deneb en ce qui concerne une éventuelle possibilité de gérer la mémoire à la main.

Mettre une référence à null n'appelle pas le GC L'objet reste en mémoire jusqu'au prochain passage du GC...
L'idée soulevée par deneb consistait à utiliser une sorte de "références particulières" qu'il faudrait libérer explicitement, pour revenir à une gestion manuelle des objets.

une reference "globale" dont on ne se sert de temps en temps ...

heu ... t'es sérieux?

Malheureusement cela se voit assez souvent

Beaucoup on du mal à comprendre que la mémoire ne se gère pas de la même manière avec et sans GC : avec un GC il est très important de bien limiter le scope des références, afin d'éviter de conserver inutilement un objet en mémoire.

a++

[epsilon68]

tout le monde deconseille de mettre les references à null,
pouvez-vous me dire si vous avez eu concretement une experience qui vous pousse à le faire maintenant? un benchmark, une experience, un vecu?

[adiGuba]

pouvez-vous me dire si vous avez eu concretement une experience qui vous pousse à le faire maintenant? un benchmark, une experience, un vecu?

Heu... non !

En général lorsqu'on est forcé de mettre une référence à null, c'est que l'on a mal choisi son scope.

a++

PS : J'ai peur de m'être mal fait comprendre : je n'ai pas dit qu'il fallait mettre les références à null... bien au contraire.

[Profman]

Un GC dans C++ est assez inconcevable, ce n'est pas du tout la philosophie de ce langage.

Au pire un GC optionnel ?

[Alp]

Personnellement, je trouve les smart pointers très très adaptés.

Dans le pire des cas, on peut bricoler quelque chose très rapidement qui force les instances de certaines classes à posséder certaines fonctions membres ou autres, notamment pour la destruction.

Après, pour moi, ça ne vaut pas de bons smart pointers !

Donc je n'utiliserai pas avant un moment un GC en C++

[SpiceGuid]

Tout à fait d'accord, le fait d'être pour le garbage-collector n'implique pas que ce soit une bonne idée pour le C/C++.
D'ailleurs ce qui va à l'encontre du style (plus ou moins) prescrit par le système de typage est rarement une bonne idée.

Par ailleurs, selon moi, le GC ne se substitue pas totalement à l'approche smart-pointers, car les smart-pointers peuvent également permettre le partage des calculs alors que le GC ne permet que le partage des cellules mémoire. Lorsqu'on veut faire un calcul sur tous les noeuds on se retrouve dans la situation où l'on veut partager les calculs sur les noeuds partagés et là le GC n'est plus d'aucun secours.

[Profman]

Personnellement, je trouve les smart pointers très très adaptés.

Dans le pire des cas, on peut bricoler quelque chose très rapidement qui force les instances de certaines classes à posséder certaines fonctions membres ou autres, notamment pour la destruction.

Après, pour moi, ça ne vaut pas de bons smart pointers !

Donc je n'utiliserai pas avant un moment un GC en C++

Je rejoins bien ce point de vue

[ac_wingless]

Tout à fait d'accord, le fait d'être pour le garbage-collector n'implique pas que ce soit une bonne idée pour le C/C++.
D'ailleurs ce qui va à l'encontre du style (plus ou moins) prescrit par le système de typage est rarement une bonne idée.

Par ailleurs, selon moi, le GC ne se substitue pas totalement à l'approche smart-pointers, car les smart-pointers peuvent également permettre le partage des calculs alors que le GC ne permet que le partage des cellules mémoire. Lorsqu'on veut faire un calcul sur tous les noeuds on se retrouve dans la situation où l'on veut partager les calculs sur les noeuds partagés et là le GC n'est plus d'aucun secours.

Le comité C++ suit de très près les GC et a tenté d'en inclure un dans le standard C++0x. Pour des raisons de temps, seule l'infrastructure facilitant l'implémentation de GC a été incluse dans le standard:

progress

A clear statement of intent was made to complete work on all features for the new standard and distribute a CD for ISO ballot following the San Francisco meeting in 2008, followed by an FCD for ballot at the end of 2009 proceeding to FDIS and final publication in late 2010.

In order to reach this goal, the threading library produced by the draughting comittee at Kona has been adopted, <...>
A second proposed compromise to meet the timetable is the scaling back of the garbage collection feature. This has now been adopted as N2670.

N2670 est un peu abscons, mais peut se résumer à ces quelques mots de Stroustrup: "We will not see GC in C++0x, but we will see further work on a design for optional and programmer-controlled GC. For C++0x, we will get a definition of what it means for a pointer to be disguised and an ABI for deeming areas of memory "not containing pointers" and/or "cannot be collected." The result of these simple guarantees will be that existing add-on collectors will be more portable and more effective."
Ce document est la base de réflexion la plus récente sur ce à quoi ressemblera le GC de C++ dans un avenir pas vraiment proche hélas. Il est cependant intéressant de le lire, pour une analyse comparative avec les smart pointers et C++/CLI (qui a le même GC agressif que C#).
Quant aux raisons pour lesquelles un GC sera utile en C++, elles sont bien présentées dans une interview récente de B. Stroustrup. Son approche pragmatique et dépassionnée du GC est rafraichissante.

[arkhamon]

Bonjour a tous !

Le papy que je suis (41 ans) va faire son vieux bougon retrograde...
Y a longtemps, j'ai fait une vrai formation en informatique (BTS informatique puis ingenieur), et j'ai un prof de programmation qui avait la devise suivante :
"un ordi c'est comme les chiottes, en sortant, on est prie de les laisser dans l'état dans lequel on l'a trouve en entrant". Ca veut dire, TOUT ce qu'on alloue, on le restitue... Ca parait con, mais j'ai JAMAIS eu un seul memory leak sur un de mes softs. Par contre je connais des applis professionnelles qui defoncent allegrement des becanes avec 4 Go de RAM par memory leak (fuite memoire, je trouve ca delicieux), ca prouve la grande efficacite du GC...

Au fait il avait une autre devise :
"une appli, ou une proc, ou un bloc, c'est 3 parrties :

• Initialisation
• traitement
• fin

Dans initialisation, on met toutes les allocations, dans traitemetn, je vous laisse deviner, et dans "fin" on doit avoir exactement les memes choses que dans init.

Alors tout ca ca donne quoi ? JE vais vous le dire. Ca fait des applications qui ont les caracteristiques suivantes :

• Pas de fuites de mémoire
• pas de crash "violation d'espace memoire"
• pas d'effets de bord indésirables...
• du code modulaire...

Desole pour mes amis DEV ils vont avoir moins de budget "debuggage et correction des defaillances".

Ah au fait j'oubliais, la definition d'un objet c'est (entre autres) une entite autonome qui se suffit, et qui contient tout ce qu'il faut pour etre interfacé. Donc si on concoit bien ses classes, on n'a pas de references circulaires comme j'ai pu le lire un peu plus haut. Et du coup on peut desallouer proprement.

Et a tous les détracteurs que je vois arriver en rang serrés pour défendre leur GC adoré qui leur permet de développer n'importe comment en dépit de toutes les règles de serieux, et qui vont poser la question : "c'est qui ce vieux c.. ? " je répondrai "c'est un mec qui a développé une application de gestion financière (gestion de portefeuilles, valorisations...) qui a tenu 5 ans sans jamais qu'on trouve un seul bug, et sna sjamais provoquer de plantages...

J'ai la faiblesse de croire que aucun hopital n'embaucherait un plombier pour faire de la chirurgie cardiaque, personne ne prendrait un dentiste poru concevoir une tour de 10 etages, alors pourquoi continuer a prendre pour du developpement des gens qui n'ont aucune formation serieuse en programmation.
Ca donne des adeptes du GC qui pour moi est une hérésie majeure, et surtout une incitation à fairre faire n'importe quoi par n'importe qui. Mais c'est pas grave, Dormez tranquilles adeptes du GC ! Derrière, y a souvent des services de support utilisateurs qui rament.

Et pour ceux qui auraient deviné, je développe en Delphi (en Win32), le compilateur est trop peu permissif pour autoriser trop de laxisme...

Voila c'etait papy qui fait de la resistance, mais qui au demeurant est un être charmant, rieur... Bon allez j'arrete...

[adiGuba]

Je suis très content pour toi si tu n'a jamais eu aucunes fuites mémoires ni aucun bug...



J'aurais toutefois quelques remarques : un GC on ne peut pas parler de "memory leak" ! Il n'y a qu'une utilisation abusive d'objet inutile...
Et les bonnes règles sont les mêmes : limiter l'utilisation des objets aux scopes le plus petit possible.

Maintenant en ce qui concerne les programmes pourris qui bouffe de la mémoire, il en existe aussi dans des langages sans GC. Quelque soit le langage on peut toujours coder comme un porc !


a++

[Matthieu Brucher]

J'ai la faiblesse de croire que aucun hopital n'embaucherait un plombier pour faire de la chirurgie cardiaque, personne ne prendrait un dentiste poru concevoir une tour de 10 etages, alors pourquoi continuer a prendre pour du developpement des gens qui n'ont aucune formation serieuse en programmation.

Malheureusement, il y a une différence entre les compétence de programmation et les compétences scientifiques. A la sortie de l'école et même après plusieurs années, certaines personnes autour de moi ne savent pas programmer, mais tiennent plus que la route au niveau scientifique. Le problème, c'est que certains croient savoir programmer...
Et avoir des personnes compétentes scientifiquement et informatiquement, c'est rare.

[alex_pi]

Ca parait con, mais j'ai JAMAIS eu un seul memory leak sur un de mes softs. Par contre je connais des applis professionnelles qui defoncent allegrement des becanes avec 4 Go de RAM par memory leak (fuite memoire, je trouve ca delicieux), ca prouve la grande efficacite du GC...

C'est sûr que si le monde n'était constitué que de génies, tout irait pour le mieux. Malheureusement, ce n'est pas le cas... Et il paraitrait même que certaines personnes ayant les capacités intellectuelles et les connaissances nécessaire pour gérer leur mémoire à la main aimeraient parfois se concentrer sur d'autre choses...

Au fait il avait une autre devise :
"une appli, ou une proc, ou un bloc, c'est 3 parrties :

• Initialisation
• traitement
• fin

Dans initialisation, on met toutes les allocations, dans traitemetn, je vous laisse deviner, et dans "fin" on doit avoir exactement les memes choses que dans init.

Sauf que là, on suppose explicitement qu'une fonction n'est pas un objet comme un autre. Que c'est quelque chose qui est là, dans mon code source, que je sais quand elle est appelée, quand elle retourne. Mais peut être que ce n'est pas nécessairement le cas ?

Ah au fait j'oubliais, la definition d'un objet c'est (entre autres) une entite autonome qui se suffit, et qui contient tout ce qu'il faut pour etre interfacé. Donc si on concoit bien ses classes, on n'a pas de references circulaires comme j'ai pu le lire un peu plus haut. Et du coup on peut desallouer proprement.

Mais qui a décrété que "classes bien conçues" implique "pas de références circulaires" ? Les références circulaires sont une erreur de conceptions *uniquement* parce que ça pose des problèmes de gestion dans le cas de "pointeurs intelligent" ou autre. En gros on s'impose une limitation (pas de GC), et on décrète que tout ce qui pose problème à partir de là est une "erreur de conception". Je suis désolé, mais si j'ai un graphe orienté, je ne vois pas pourquoi une cellule ou un sommet n'aurait pas le droit d'avoir une liste de ses voisins. Je ne vois pas en quoi le fait de dire "mon objet connait ses voisins" est une "erreur de conception". Il s'avère que ça ne colle pas avec ta vision de la gestion de la mémoire, ok, mais de là à dire que c'est intrinsèquement "mauvais", il y a quand même du chemin...

je répondrai "c'est un mec qui a développé une application de gestion financière (gestion de portefeuilles, valorisations...) qui a tenu 5 ans sans jamais qu'on trouve un seul bug, et sna sjamais provoquer de plantages...

Il paraitrait que l'argument "je suis un mec sérieux, je bosse dans la finance" fonctionne vachement moins bien ces derniers temps :-)

J'ai la faiblesse de croire que aucun hopital n'embaucherait un plombier pour faire de la chirurgie cardiaque, personne ne prendrait un dentiste poru concevoir une tour de 10 etages, alors pourquoi continuer a prendre pour du developpement des gens qui n'ont aucune formation serieuse en programmation.

Ouais, faudrait faire passer des tests drastiques à tous les ptits cons qui veulent programmer un utilitaire sympa à mettre dans une distro linux. Laissez les pros bosser !

[adiGuba]

Juste une remarque : j'ai un peu l'impression que le GC est perçu comme une aide aux mauvais développeurs

Je le perçois exactement à l'envers : c'est une aide aux développeurs qui veulent se concentrer sur leurs codes métiers et non pas sur un coté technique nécessaire mais pas forcément intéressant et utile...


Pour reprendre l'analogie avec le chirurgien, s'occuper manuellement de la mémoire reviendrait à ce qu'il s'occupe de nettoyer les pansements après une opération...

Il paraitrait que l'argument "je suis un mec sérieux, je bosse dans la finance" fonctionne vachement moins bien ces derniers temps :-)

a++

[Alp]

A mon avis le GC fait un peu les deux : il aide ceux qui ne savent pas très bien programmer et limite donc la casse en ce qui concerne la gestion de la mémoire, et il aide également ceux qui connaissent bien les petites ficelles et leur permet de ne se concentrer que sur le code métier. La qualité des programmes du premier type et du second type de programmeurs est assez différente comme vous vous en doutez

[Furikawari]

Je suis intimement convaincu qu'il y a une forte dimension psychologique dans le rejet systématique du GC par certains. Genre "ce qui fait un vrai programmeur c'est sa capacité à gérer la mémoire".

[gorgonite]

Mais qui a décrété que "classes bien conçues" implique "pas de références circulaires" ? Les références circulaires sont une erreur de conceptions *uniquement* parce que ça pose des problèmes de gestion dans le cas de "pointeurs intelligent" ou autre. En gros on s'impose une limitation (pas de GC), et on décrète que tout ce qui pose problème à partir de là est une "erreur de conception". Je suis désolé, mais si j'ai un graphe orienté, je ne vois pas pourquoi une cellule ou un sommet n'aurait pas le droit d'avoir une liste de ses voisins. Je ne vois pas en quoi le fait de dire "mon objet connait ses voisins" est une "erreur de conception". Il s'avère que ça ne colle pas avec ta vision de la gestion de la mémoire, ok, mais de là à dire que c'est intrinsèquement "mauvais", il y a quand même du chemin...

faudrait quand même que certains arrêtent de s'imaginer que les références circulaires ne peuvent pas être gérées sans GC...
je ne dis pas que c'est trivial a priori, mais dans les messages précédents on trouve des exemples de choses "standards" en C++ qui permettent de régler ce problème (j'ai pas dit dans la STL)

attention, je n'ai pas dit non plus qu'utiliser un GC était mal... en revanche, j'aime bien quand on évite d'affirmer qu'une chose est impossible alors qu'il existe des outils qui prouvent le contraire
@alex_pi: ce n'est pas contre toi personnellement bien sur, mais je trouve que ce débat tourne souvent à l'affrontement de personnes ne connaissant au mieux qu'un seul aspect du problème, et qui généralisent un peu vite

Je suis intimement convaincu qu'il y a une forte dimension psychologique dans le rejet systématique du GC par certains. Genre "ce qui fait un vrai programmeur c'est sa capacité à gérer la mémoire".

tout comme on a l'impression que certains ont un problème psychologique avec le fait que certains "bons" programmeurs fassent des très gros projets tout en utilisant des langages sans GC

[Alp]

faudrait quand même que certains arrêtent de s'imaginer que les références circulaires ne peuvent pas être gérées sans GC...
je ne dis pas que c'est trivial a priori, mais dans les messages précédents on trouve des exemples de choses "standards" en C++ qui permettent de régler ce problème (j'ai pas dit dans la STL)

C'est dans le Technical Report 1 et presque tous les compilos l'intègrent... Et ca fait une dizaine d'années que la technique a émergé.
http://loic-joly.developpez.com/tuto...mart-pointers/

[souviron34]

...
snip
....

Je suis assez d'accord avec toi.. Pas totalement, mais à plus de 90% (il y a quelques fuites )

Pour ce qui est des explosions de mémoire, n'importe quel utilisateur de Windows le voit régulièrement... De même que le "patinage" en boucle de connexions....

faudrait quand même que certains arrêtent de s'imaginer que les références circulaires ne peuvent pas être gérées sans GC...
je ne dis pas que c'est trivial a priori, mais dans les messages précédents on trouve des exemples de choses "standards" en C++ qui permettent de régler ce problème (j'ai pas dit dans la STL)

attention, je n'ai pas dit non plus qu'utiliser un GC était mal... en revanche, j'aime bien quand on évite d'affirmer qu'une chose est impossible alors qu'il existe des outils qui prouvent le contraire
@alex_pi: ce n'est pas contre toi personnellement bien sur, mais je trouve que ce débat tourne souvent à l'affrontement de personnes ne connaissant au mieux qu'un seul aspect du problème, et qui généralisent un peu vite



tout comme on a l'impression que certains ont un problème psychologique avec le fait que certains "bons" programmeurs fassent des très gros projets tout en utilisant des langages sans GC

on ne peut pas mieux dire

Quoique certains en pensent, vos téléphones portables, vos écrans plats, vos MMS, vos GPS etc etc.. ont été développés par des personnes ayant appris et/ou développé avec des outils qui, même si vous les considérez comme archaiques, n'en sont pas pour autant fiables, dès qu'on fait attention à ce qu'on fait...

(j'avais d'ailleurs lancé ou participé à une discussion sur RAD et IDE qui rejoignait ce point).

Et si ces "nouveaux" outils étaient si "parfaits" que ça, comment se fait-il qu'il y ait encore des bugs dans les applis ???

[adiGuba]

Mon C++ est loin et je n'ai jamais utilisé de Smart Pointer...

Par contre sauf erreur de compréhension de ma part, les Smart Pointer font en partie la même chose que le GC, en ce qui concerne la libération de la mémoire en tout cas (le GC fait plus que cela puisqu'il s'occupe aussi de l'allocation et de la gestion de la zone mémoire).

Non ?

a++

[alex_pi]

@alex_pi: ce n'est pas contre toi personnellement bien sur, mais je trouve que ce débat tourne souvent à l'affrontement de personnes ne connaissant au mieux qu'un seul aspect du problème, et qui généralisent un peu vite

Pas de soucis ;-) C'était une réponse spécifique à son commentaire sur le mauvais design. Bon après, dans le cas de mon graphe, ça veut dire qu'il faut une liste de pointeur vers tous les sommets et que chaque sommet n'a qu'une liste de weak pointers vers ses voisins, ce qui fait qu'une composante non connexe n'est pas automatiquement détruite, mais on va dire qu'on chipote

J'espère n'avoir jamais dit que la gestion "manuelle" de la mémoire (par opposition à avec GC, pas uniquement à coup de malloc et free) n'est pas possible (la preuve en étant que c'est une des situations les plus courante), mais je continue à penser que le GC est un apport majeur dans de nombreux cas et qu'il apporterait à beaucoup.

@souviron34 : qui a dit qu'un GC empéchait les bugs ? Ca empeche *certains* bugs !