Discussion :

[mazertys17]

Bonjour, j'aurais quelques questions à propos des HashMaps pour les connaisseurs.

Est-il possible d'arrêter de parcourir une boucle avec EntrySet ?

ex :

Code :

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

1
2
3
4
5
6
7
 
for ( Map.Entry<Integer,String> entry : maMap.entrySet()){
       if ( entry.getValue().equal("test"){
               fonctionX.doSomething();
               entry.end();
       }
}

Autre question.
Les HasMaps sont-il nécessairement triés dans un ordre de construction comme dans un ArrayList ou (comme j'ai l'impression), leur ordre peut varier de façon aléatoire ou autre ?

[joel.drigo]

Salut,

Est-il possible d'arrêter de parcourir une boucle avec EntrySet ?

Oui, par exemple comme tu fais :

Code :

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

1
2
3
4
5
6
7
 
for ( Map.Entry<Integer,String> entry : maMap.entrySet()){
       if ( entry.getValue().equal("test"){
               fonctionX.doSomething();
               entry.end();
       }
}

sauf entry.end() qui n'exsite pas (la clef s'obtient par getKey() par ailleurs) (et puis c'est equals() pas equal())

Tu peux également utiliser les streams, puisque l'entryset est un Set (maMap.entrySet().stream()...

Autre question.
Les HasMaps sont-il nécessairement triés dans un ordre de construction comme dans un ArrayList ou (comme j'ai l'impression), leur ordre peut varier de façon aléatoire ou autre ?

Non, en effet, l'ordre de parcours ne correspond pas à l'ordre d'insertion avec une HashMap. Il dépend des tables de hashage, donc de la répartition des hashcodes des clefs : autant dire qu'on ne peut le prendre en compte. Tu peux néanmoins obtenir ce comportement en utilisant une LinkedHashMap.

[mazertys17]

Merci Joel Drigo,

Mais pourrais tu être plus précis sur le code pour finir la boucle ?
Je n'ai pas trouvé de fonction " entry.getKey().end() "

[joel.drigo]

La boucle se finit d'elle-même lorsque on a itéré sur l'ensemble des entries. C'est le principe d'un itérateur... (un forEach utilise un itérateur).

Pourquoi vouloir appeler une hypothétique méthode getEnd() ? Tu as besoin de faire un traitement spécial sur la dernière entrée ?

[adiGuba]

Salut,


Pour arrêter une boucle on utilise tout simplement un break :

Code :

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

1
2
3
4
5
6
for ( Map.Entry<Integer,String> entry : maMap.entrySet()){
       if ( entry.getValue().equal("test"){
               fonctionX.doSomething();
               break;
       }
}

a++

[mazertys17]

Merci !

Je vais essayer cela.

C'est simplement pour éviter de parcourir le reste d'une boucle pour rien quand l'élément a été trouvé et d'autre part, s'il y a un traitement qui doit être appliqué avec une donnée présente dans des clefs différentes et ne doit l'être qu'une fois, il est nécessaire d'arrêter de parcourir la boucle pour empêcher que ce traitement soit fait plusieurs fois.
On peut mettre un système de condition mais c'est lourd, aussi bien dans le code que dans les performances sans doute.

Donc merci, je vais voir avec un break.
Jusqu'à maintenant, je procédais avec des Iterators, mais j'ai quelques plantages qui y sont sans doute liés :

Une autre question bête.
Comment fait-on pour avoir accès simplement a une donnée d'un HasMap sans avoir a parcourir systématiquement la boucle ?

Si on fait :

Code :

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

1
2
3
4
5
 
 
                val1 = maMap.get(17).value1 ;
                val2 = maMap.get(17).value2 ;
                ect...

il parcour 2 fois la boucle non?

Comment faire l'équivalent de ca par ex :

Code :

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

1
2
3
4
5
 
                Set key = (Set)maMap.get(17);
                val1 = key.getValue().value1 ;
                val2 = key.getValue().value2 ;
                ect...

[joel.drigo]

Ah, oui, je n'avais pas compris le sens de la question pour le break

Merci !
Une autre question bête.
Comment fait-on pour avoir accès simplement a une donnée d'un HasMap sans avoir a parcourir systématiquement la boucle ?

Si on fait :

Code :

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

1
2
3
4
5
 
 
                val1 = maMap.get(17).value1 ;
                val2 = maMap.get(17).value2 ;
                ect...

il parcour 2 fois la boucle non?

On accède simplement à la valeur par la méthode get( laclef ) :

Code :

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

val1 = maMap.get(17);

Il n'y a pas de boucle dans ton extrait de code. Il n'y a donc aucun parcours de boucle explicite. Après, si tu parles de ce qui se passe en interne à la HashMap, c'est un autre problème.

Comment faire l'équivalent de ca par ex :

Code :

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

1
2
3
4
5
 
                Set key = (Set)maMap.get(17);
                val1 = key.getValue().value1 ;
                val2 = key.getValue().value2 ;
                ect...

Il n'y a pas d'équivalent de ça : la map est déclarée Map<Integer,String>, caster la valeur en Set provoque donc un ClassCastException. Je ne vois même pas ce que tu cherches à faire.

[mazertys17]

Ok, merci.

Non c'était plutôt pour savoir s'il y avait un moyen de limiter les boucles implicites.
J'essaye surtout de comprendre un peu mieux comment ça marche, à mon niveau.

Une autre question niveau mémoire en Java.
Quand on crée un objet dans un autre objet et qu'on le met dans une HashMap par exemple, il met un pointeur sauf erreur.
Mais l'objet va-t-il, dans la compilation, être placé au bon endroit dans la HashMap ?

En somme, il y a t-il une différence entre ceci :

Code :

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

1
2
3
 
Object obj = new Object("test", 8, 1.5 ) ;
maMap.put(4,obj );

et ceci :

Code :

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

1
2
 
maMap.put(4, new Object("test", 8, 1.5 ) );

(Sachant qu'on va utiliser que cette HashMap pour avoir accès a l'objet).

[tchize_]

les pointeurs ça n'existe pas en java, on parle de référence.

Tes deux codes sont fonctionellement équivalent. La différence c'est que dans le premier t'aura une variable en plus

[mazertys17]

"fonctionnellement", oui...Mais en terme de mémoire, est-ce strictement la même chose ?
( a part le fait qu'il y a une variable en plus ).

Je veux dire par là...seront-ils mis au même emplacement mémoire ?

J'essaye de construire mon programme sur un modèle d'Entity Composant Système / Data Driven, donc l'idée est de poser les données correspondantes les unes a côtés des autres pour plus de performance lors de leur utilisation.

[tchize_]

ouais ben en java tu oublie, la jvm se charge d'optimiser ce qui doit l'être et l'emplacement mémoire n'est pas sous ton controle. Et on n'est pas comme en C++ où il y a une différence entre les objets créés par malloc et les objets statique. Dans tes deux exemple, java va allouer un objet et mettre sa référence dans la hashmap.

[mazertys17]

Ok.
Merci.

[mazertys17]

Autre question s.v.p niveau perfs.

Est-il mieux de créer des variables ou containers (type HashMaps ou ArrayList par ex) dans un object ( donc la mémoire sauf erreur ) ou a la volée ?

ex :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
 
class Object {
 
    ArrayList<Bidul> array;  
 
Object(){
   array = new ArrayList<Bidul>();
}
fonction utilisation(){
array.clear() ;
for( Bidul b : bidul){
       if (b.truck()){
            array.add(b)
       }
}

ou au contraire simplement :

Code :

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

1
2
3
4
5
6
7
8
 
fonction utilisation(){
ArrayList array = new ArrayList<Bidul>();
for( Bidul b : bidul){
       if (b.truck()){
            array.add(b)
       }
}

C'est sans doute de l'ordre du détail mais c'est surtout pour comprendre mieux .

[tchize_]

ben ça dépend, dans le premier cas, ton ArrayList est un champ de l'objet, il vit avec l'objet, perdure d'un appel à un autre. Dans le second cas, tu as créé une instance temporaire que tu jette après usage. Ca dépend de ce que tu as besoin. Ce que tu n'a pas besoin de conserver après l'appel de méthode n'a rien à faire dans les champs, c'est local à la méthode.

Ca ne change pas a priori l'emplacement mémoire où il est instancicé.

[adiGuba]

Autre question s.v.p niveau perfs.

La GROSSE erreur c'est de penser performance à ce niveau là.
C'est le meilleur moyen de faire un code tout pourri...


Le meilleur emplacement pour un variable, c'est là où on en a besoin. Et uniquement là.
Dans 99% des cas ce sera la meilleure utilisation.


Dans le 1% des cas restant, lorsqu'on détecte un problème de performance, on aura un code propre à étudier pour déterminer l'origine du problème.


a++