Passage d'argument entier

Bonjour,

Je ne me rapelle plus quelle est la raison (théorique) du non fonctionnement du code suivant:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

protected TreeMap<Double,Integer> t; protected int nbL = 0 ;   public void initialiser(){ t = new TreeMap<Double,Integer>(); incrementer(t,nbL); System.out.println(nbL) ; // = 0 ; et non 1 pourtant l'incrémentation a été faite }   public void incrementer(TreeMap<Double,Integer> x, int n){ x.add(0.0,1) // -> cela marche qd on fai t.get(0.0) : on ajoute bien ds la treemap t   par contre n++; }   }

---

Merci d'avance, je ne sais plus pourquoi on incrémente pas nbL (raison static, emploi de setNbL.. autres?)

Tout simplement car au moment de l'appel : incrementer(t,nbL) l’exécution saute dans la méthode incrementer. Tes argument t et nbl sont recopiés dans les paramètres x et nbl. C'est ce que l'on appelle le passage de paramètre par recopie.

La méthode appelée travaille sur ces variables recopiées qui sont perdues quand elle se termine.

Il y a passage par référence en java : si tu passe en paramètre une instance d'un objet à une méthode. Et dans cette méthodes si tu modifie l'objet, l'objet seras bien modifié à sa sortie.

MAIS, les types primitifs(int, float, double, boolean, ...) sont passé par copie.
Donc dans ta méthodes tu modifie juste une copie :P.

Mais comment faire alors?
Utiliser Integer au lieu de int peut-être une solution

Citation:

---

Envoyé par Ivelios

Utiliser Integer au lieu de int peut-être une solution

---

Hmmm. C'est un gros piège ça. Integer étant immutable il va rien changer à ça.
L'idée c'était un exercice, genre "c'est peut-être une solution sauf que si tu essaies tu verras que non" ?

Citation:

---

L'idée c'était un exercice?

---

Oui, exactement :whistle2:

Maintenant je me fais tout petit, et j'attends que ça se tasse :aie:

Citation:

---

Envoyé par Ivelios

Il y a passage par référence en java : si tu passe en paramètre une instance d'un objet à une méthode. Et dans cette méthodes si tu modifie l'objet, l'objet seras bien modifié à sa sortie.

---

Non , ce n'est pas un passage par référence au sens ou on l'entend habituellement. Si tu passe un objet en paramètre il y a copie de la référence de l'objet. Mais si tu modifie la référence dans la méthode, cela restera sans effet a l'extérieur de la méthode.

Citation:

---

Mais si tu modifie la référence dans la méthode, cela restera sans effet a l'extérieur de la méthode.

---

On ne modifie pas la référence mais l'objet pointé par la référence. :?
Donc si tu modifies l'objet pointé par la référence, l'objet restera modifié à l'extérieur de la méthode et la référence (copié) de la méthode sera supprimé.

En faite je pense qu'on veux dire la même chose , j'ai du m'emmêler dans mes mots.:aie:

Récapitulons, dans tous les cas tu passes la copie de quelque chose.
-> Soit la copie de la référence d'un objet
-> Soit la copie d'un type primitif

Ok, je vois (mes cours me sont revenus à l'esprit). Je ne me rapellais plus l'exception pour les types primitifs.

Il y a donc deux solutions pour pallier à ce problème concernant l'incrémentation de la valeur nbL (la treemap n'étant pas effectué, car la référence pointe toujours sur le bon objet).

soit j'effectue un setNbL à la fin de incrémenter.
soit je renvoie la valeur : this.nbL = incrementer(t,nbL)

Est-ce bien là toutes les solutions?

... Soit tu enlèves le paramètre n de ta méthode incrémenter puisqu'il n'a rien à faire là, et tu te sers de la variable membre nbL à la place.

En effet, je n'ai pas parlé de cette solution car en réalité il y a deux variables t_1 et t_2 puis nbL_1 et nbL_2 qui scanne un fichier, et si on scanne pour ajouter dans t_1 on incrémente nbL_1 sinon on incrémente nbL_2. Du coup, il faut que je sache quelle valeur incrémentée, je pouvais ajouter un booléen et utiliser la méthode avec set. Mais je préfère l'emploi de la méthode où je retourne la valeur.

Merci pour votre aide, je marque la discussion !