Discussion :

[Faiche]

Bonjour,

J'ai une map qui prends en clé un objet Obj1, et en valeur une list d'objets Obj2:

Code :

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

1
2
 
Map<Obj1, List<Obj2>> map = ... ;

Je remplis une liste d'obj2 dans une fonction, et je l'ajoute dans la map

Code :

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

1
2
 
map.put(o1, maliste)

Si après l'ajout, je fais un maliste.clear(), est ce que ça va vider aussi le contenu de la liste dans la map ?

Merci

[DevTeam_]

Oui, ce n'est qu'une histoire de références...

[Faiche]

Alos aucune collection ne fait jamais de copie ?

Et d'ailleurs, je suis dans un scope, je déclare et je remplis une list, que je ne clear pas. Quand je sors du scope, c'est comme si un clear avait été appellé ?

C'est quand même une connerie de n'avoir ni de destructeur, ni de delete.

[djo.mos]

bonjour,

C'est quand même une connerie de n'avoir ni de destructeur, ni de delete.

Bon, peut on savoir pourquoi ? Du moment que rien ne référence plus un objet, celui-ci est un candidat au garbage Collecting. Qu'est ce qui est con la dedans ?

[Faiche]

bonjour,

Bon, peut on savoir pourquoi ? Du moment que rien ne référence plus un objet, celui-ci est un candidat au garbage Collecting. Qu'est ce qui est con la dedans ?

Ce qui est con dedans, c'est qu'on n'a aucun moyen de savoir si telle fonction ou tel objet va faire une copie de notre objet ou pointer dessus.

Au moins, en c++ Objet, Objet& et Objet* sont des types totalement différents, et on sait immédiatement s'il y a une copie ou un pointage.

Tu le dis très justement : si plus rien ne pointe sur la zone mémoire, c'est candidat au GC, mais comment on sait réllement que plus rien ne pointe dessus ?

[T`lash]

Si tu connais bien ton code tu sais ce que tu fais de tes objets ; et donc lorsque toutes les références à un objet dirigent vers autre chose ou ont été détruites.

Dans la plupart des cas (si cela a été bien fait), tu sais grâce à la Javadoc si une méthode génère une copie ou travaille par référence.

Si tu veux réellement qu'une copie d'un de tes objets soit utilisé, tu n'as qu'à la générer toi-même (c'est à ça que sert la méthode clone() qu'il est intéressant de surcharger dans une grande majorité des cas).

[djo.mos]

Tu le dis très justement : si plus rien ne pointe sur la zone mémoire, c'est candidat au GC, mais comment on sait réllement que plus rien ne pointe dessus ?

C'est pas à toi de le savoir, c'est au GC.
Comment savoir si rien ne pointe plus sur un objet ? Je crois que tu crains surtout d'accéder à un objet qui a été détruit, ce qui donne la fameuse Read at XXXXX ? ça n'arrivera tout simplement jamais, car quand rien ne référence plus l'objet en question, et bien tu ne peux même pas essayer d'y accéder ! t'as pas une variable ou un chmp qui pointe la dessus !

Sinon, je te ferais remarquer que la notion de Garbage collecting est là depuis des decennies et qu'elle a fait ses preuves que ce soit dans Java oiu autres langages, et que personne ne s'en plaint (enfin, presque).
Bref, essayons de ne pas tomber dans le piège d'un milliardième troll C++ vs Java

[Nikoui]

Tu le dis très justement : si plus rien ne pointe sur la zone mémoire, c'est candidat au GC, mais comment on sait réllement que plus rien ne pointe dessus ?

La réponse à la question est : tu ne te poses pas la bonne question

Qu'est ce que ça peut te faire de savoir si l'objet est encore référencé ou non, puisque ce n'est pas toi qui va décider de le détruire ?

C'est un pas difficile à franchir, mais il faut juste déléguer complètement la gestion de la mémoire au GC et lui faire confiance. Il sait ce qu'il fait, est programmé (proprement) pour...

[Faiche]

C'est un pas difficile à franchir, mais il faut juste déléguer complètement la gestion de la mémoire au GC et lui faire confiance. Il sait ce qu'il fait, est programmé (proprement) pour...

Toi t'es le genre de mec a pondre des codes comme ça :

Code :

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

1
2
3
4
5
6
 
while (true)
{
   MyObject mo = new MyObject();
   ..
}

Le GC est loin d'être magique. Les API Java sont loin d'être bien pensées, et généralement, dans une application il n'y a pas qu'un seul developpeur.

Du coup il est impératif de controller ce qu'on peut controller, et de prier pour que personne ne chie dans la colle a coté.

Un exemple : les api de sérialisation de Java font des copies dans tous les sens, du coup, en faisant confiance comme tu dis, ça craque après une dizaine d'objets \o/

Comment savoir si rien ne pointe plus sur un objet ? Je crois que tu crains surtout d'accéder à un objet qui a été détruit, ce qui donne la fameuse Read at XXXXX ? ça n'arrivera tout simplement jamais, car quand rien ne référence plus l'objet en question, et bien tu ne peux même pas essayer d'y accéder ! t'as pas une variable ou un chmp qui pointe la dessus !

Je ne crains pas d'acceder à une variable détruite, je crains que mes variables ne soient jamais détruites !

Si tu connais bien ton code tu sais ce que tu fais de tes objets ; et donc lorsque toutes les références à un objet dirigent vers autre chose ou ont été détruites.

Dans la plupart des cas (si cela a été bien fait), tu sais grâce à la Javadoc si une méthode génère une copie ou travaille par référence.

Comme je l'ai dit, mon code je le connais, le reste non.

Et dans la plupart des cas, la javadoc a été faite n'importe comment.

Sinon, je te ferais remarquer que la notion de Garbage collecting est là depuis des decennies et qu'elle a fait ses preuves que ce soit dans Java oiu autres langages, et que personne ne s'en plaint (enfin, presque).

Le principe du GC c'est une idée géniale. Mais par exemple le C# lui permet quand même à un utilisateur de libérer sa mémoire !

Le GC est la pour rattraper ce qui est hors de portée, de limiter la casse quand une exception est levée, et de ne pas craquer toute la mémoire. Pas pour faire le boulot a notre place, il est pas magique.

[T`lash]

Le GC est la pour rattraper ce qui est hors de portée, de limiter la casse quand une exception est levée, et de ne pas craquer toute la mémoire. Pas pour faire le boulot a notre place, il est pas magique.

Sur ce point je suis bien d'accord avec toi.

[the-gtm]

Les API Java sont loin d'être bien pensées

Par rapport à quoi?

Un exemple : les api de sérialisation de Java font des copies dans tous les sens, du coup, en faisant confiance comme tu dis, ça craque après une dizaine d'objets \o/

La serialisation standard ne fait pas de copies et marche très bien, même jusqu'à 11 objets, voire 12

Et dans la plupart des cas, la javadoc a été faite n'importe comment.

Celle de l'API standard est bien faite et détaillée, après pour les librairies externes ça dépend de forcément de qui l'a écrite.


Ecoute, c'est normal que ça déroute un peu, la façon de programmer est différente entre C++ et Java du point de vue de la gestion de la mémoire.
Maintenant si tu te pose ce genre de questions, il ne faut pas à chaque fois te dire a priori que c'est une "connerie".

[dingoth]

Je ne crains pas d'acceder à une variable détruite, je crains que mes variables ne soient jamais détruites !

Deux méthodes pour t'en assurer :
* si l'objet est un conteneur (liste, map, etc) : utilise la méthode clear();
* ensuite, pour chaque objet (conteneur ou pas), prends la bonne habitude de faire : Object a = ...; ... ; a = null;

Le fait d'attribuer null à a le met dans la liste des objets prioritaires à supprimer par le GC. De même attribuer une nouvelle valeur à a en supprime l'ancienne et ajoute cette dernière dans la liste à gérer par le GC.

Mais bon, il ne faut pas dire que la gestion de la mémoire est pourrie en java, si on n'a pas fait un minimum de recherche pour savoir comment la gérer. C'est comme en C++, si je détruis pas un objet, bah... il reste en mémoire. En java, c'est pareil, sauf qu'il a plus de chance d'être détruit quand même si y'a plus que 0 réf sur lui.

Pour répondre à ta question initiale, NON, ça ne videra pas ta liste contenue dans ta map ! C'est à toi de le faire en clear()ant cette liste.

Je ne répondrai pas au troll de la javadoc, toutefois.

[adiGuba]

Salut,

Les API Java sont loin d'être bien pensées,

C'est à dire ?

Du coup il est impératif de controller ce qu'on peut controller, et de prier pour que personne ne chie dans la colle a coté.

Lorsqu'on utilise un GC, le controle ne consiste pas à appeler un "delete" mais à bien limiter la porté des scopes des objets, et d'éviter de conserver un objet inutilement.

Lorsque tu vides une collection, tous les objets qu'elle contenait seront bien sûr éligibles à la destruction, à moins que tu ne conserves une autre copie de la référence autre part...

Un exemple : les api de sérialisation de Java font des copies dans tous les sens, du coup, en faisant confiance comme tu dis, ça craque après une dizaine d'objets \o/

Tu pourrais justement donner un exemple de ce que tu avances (avec de vrai morceaux de code dedans ).

Je ne crains pas d'acceder à une variable détruite, je crains que mes variables ne soient jamais détruites !

Si elle ne sont jamais détruite, cela signifie que tu en conserves une référence quelque part.

Et dans la plupart des cas, la javadoc a été faite n'importe comment.

Encore une fois : pourrais-tu donner un exemple concret plutôt que de d'avancer dans de telles déclarations

Le principe du GC c'est une idée géniale. Mais par exemple le C# lui permet quand même à un utilisateur de libérer sa mémoire !

Le GC est la pour rattraper ce qui est hors de portée, de limiter la casse quand une exception est levée, et de ne pas craquer toute la mémoire.

Non : le GC est chargé de gérer la mémoire utilisé par les objets, et de détruire les objets qui ne sont plus référencé.

Pas pour faire le boulot a notre place, il est pas magique.

Mais pourquoi voudrais-tu faire son boulot à sa place ?


a++

[T`lash]

Le GC n'est pas magique mais il fait plutôt bien ce qu'il est sensé faire.

La seule interaction que tu peux avoir avec lui c'est de lancer manuellement son passage dans des cas extrêmement rares.

La part du travail à la charge du développeur est de faire attention de ne pas laisser trainer des références.
Ne pas utiliser de propriétés lorsque variable locale serait plus appropriée et gérer correctement les Collection.