Discussion :

[Hyssgrif]

Bonjour,

Question culture générale:

Je ne comprends pas pourquoi Java a fait le choix de s'en remettre corps et âme a son garbage collector et n'autorise pas les développeurs a utiliser des fonctions comme "delet(this.classe)"

Merci à vous!

[tchize_]

Parce que autoriser un delete, c'est autoriser que l'utilisateur continue d'utiliser l'objet après le delete. Ce qui pose alors problème puisque le programme à alors accès à une zone mémoire qui ne lui est plus attribué, via l'ancienne reference. Viennent alors des problèmes de type corruption de mémoire que java veux rendre impossibles, les problèmes de sécurité, et la difficulté pour le programmeur de savoir si réellement l'objet n'est plus utilisé.

[OButterlin]

D'abord, java n'est pas le seul langage à utiliser un garbage collector, même .net s'y est mis...

Je ne suis pas d'accord avec toi, le programmeur peut très bien agir pour qu'un objet soit éligible au GC, il suffit de supprimer toutes les références à cet objet... et c'est là que le bât blesse... en est-il capable ? Dans bien des cas, non...
Du coup, ce que te dit tchize_ prend tout son sens. Il vaut mieux utiliser un mécanisme du type GC que de rendre possible une référence sur un objet qui n'existe plus, tu imagines les effets de bord ? Non... et personne ne le peut

Bref, à mon sens, le GC est un très bon mécanisme et personnellement, je ne reviendrais pas dessus.
La plupart de ceux qui le critiquent sont des programmeurs qui viennent du langage C, en oubliant qu'à la base ce langage a été conçu pour écrire un OS (Unix) et en omettant également toutes les "bavures" qu'il autorise quand il est employé par des débutants...

[tchize_]

Dans bien des cas, non...

Je rajouterais qu'en général, quand le programmeur en est capable, ce sont des cas tellement simple que ça ne représente rien comme travail pour le GC

[OButterlin]

Je rajouterais qu'en général, quand le programmeur en est capable, ce sont des cas tellement simple que ça ne représente rien comme travail pour le GC

C'est pas faux

Souvent, c'est le syndrome : je veux le beurre et l'argent du beurre...
Je veux des références d'objets, les passer comme je veux, à qui je veux (sans savoir forcément ce qui en est fait), les stocker où je veux... mais je ne me rappelle plus où !

[Gugelhupf]

Les concepteurs de Java n'ont pas ajouté d'instruction delete parce qu'ils voulaient justement supprimer cette contrainte du C++.
Aujourd'hui tu as les normes C++11 et C++14, mais le problème du delete existe depuis plus de 30 ans et continuera d'exister.
Ce que tu dois comprendre, c'est qu'avoir l'instruction delete en Java ne servirait à rien parce que ce dernier se débrouille tout seul pour libérer la mémoire. Pour les cas spécifiques le langage t'offre la possibilité de gérer la mémoire d'une autre façon grâce aux types SoftReference ou WeakReference par exemple.

[Hyssgrif]

Merci à vous pour vos réponses!

Aujourd'hui en C++ nous avons les smart pointeurs qui se débrouillent pour supprimer toutes références à l'objet si celui ci est "delete". Donc pas de risque d'accès mémoir vide.
Je me demande si le garbadge collector est toujours aussi fiable (quand on regarde MineCraft et les bug ou lenteur après X heures de jeu, liés, si je ne m'abuse, à un trop plein d'objets cumulés non supprimés, je me demande...)

[adiGuba]

Salut,

Aujourd'hui en C++ nous avons les smart pointeurs qui se débrouillent pour supprimer toutes références à l'objet si celui ci est "delete". Donc pas de risque d'accès mémoir vide.

Mais les smart-pointeurs ne sont pas aussi efficace qu'un Garbage Collector.
Par exemple sauf erreur de ma part ils se contentent de compter les références pour "supprimer" l'instance, et ne peuvent pas gérer les références croisés.

De plus le GC gère la mémoire plus globalement, et permettra généralement de meilleurs résultats en cas d'allocation/désallocation de nombreux objets...


Le principal défaut du GC c'est de ne pas avoir une maitrise exacte de la mémoire utilisé, mais cela concerne plutôt les système embarqué avec un espace mémoire restreint.

Je me demande si le garbadge collector est toujours aussi fiable (quand on regarde MineCraft et les bug ou lenteur après X heures de jeu, liés, si je ne m'abuse, à un trop plein d'objets cumulés non supprimés, je me demande...)

Le Garbage Collector de Java est fiable : il n'y a pas de doute là dessus.

Mais cela ne veut pas dire que les programmes qui l'utilise seront forcément bien codé !
Si la mémoire de MineCraft "explose", ce n'est sûrement pas la faute du GC, et ce ne serait sûrement pas mieux avec une mémoire managée manuellement (au contraire même puisqu'il faudrait être encore plus strict).

A mon avis ce serait même pire, puisqu'en plus d'être consommateur en mémoire, on aurait le risque d'avoir des fuites mémoires...


a++

[tchize_]

Minecraft n'est certainement pas une reference pour parler de java. Quand un serveur de jeu demande plus de 8g pour y mettre 4 joueurs, il faut sérieusement se poser des questions sur les choix des développeurs. Pour comparer, prends azureus, le client bit torrent. Il manipule des gigas de données et a une empreinte mémoire plus que raisonnable.