Salut,
Lorsque l'on fait

aucune string n'est crée en plus de str, on dit juste que s pointe sur la chaine pointée
par str, c'est ça ?
Donc je comprends pas pourquoi ce code compile mais ne mofifie pas la chaine passée en paramètre
 

 
et s n'est pas modifiée (quand je l'affiche après l'appel à modifyString par exemple).
Est-ce une raison de portée de variable (cantonnement à l'environnement local de la fonction) ?
 
merci
   ANT

Par exemple,
 
http://www.janeg.ca/scjp/pkglang/immutable.html

* soupir * je regrette les bons vieux &...

Oui en effet, je savais bien que les String ne sont pas modifiables, mais dans mon exemple, en fait je change juste vers quoi pointe s, c'est pas bon, y a un truc qui m'échappe ?
Donc comme dans le lien que tu m'as filé, je réaffecte un nouvel objet (read-only) à s. Et pourquoi quand je sors de la fonction s pointe toujours sur l'ancien objet ?
merci

 
 
et accessoirement va lire le topic d'nraynaud sur les string

parce que les paramètres des méthodes sont locaaux aux méthodes ... il ne s'agit pas de la même variable que celle avec laquelle tu as fait l'appel. C'est uen autre variable qui pointe vers le même objet => si tu fais pointer la variable locale à ta méthode vers un autre objet, ca ne change rien pour la variable externe.
 
C'est du au fait qu'en java le passage des paramêtres se fait par copie de valeur (copie de l'adresse mémoire de l'objet pointé, dans le cas d'objet). un peu comme en C ... comme les paramêtres de type IN en ADA, comme les paramêtres qui n'ont pas de '&' en C++ (sauf que là c'est carrément l'objet qui est dupliqué)

euh encore, pour la énième fois, confondage là. ça se passe comme ça uniquement parce que c'est des String.
passe un autre type à ta methode modifyString et il sera toujours "modifié" a la sortie de cette methode
 
 
 

non, il change juste la variable la

tu vas pas recommencer !!!
 
si tu affecte une autre valeur à la variable (s = "toto" ) ca ne changera JAMAIS rien pour la variable externe.
 
Par contre, bien sur, dans le cas d'objets qui ne sont pas immuables, si tu appelles dessus des méthodes qui changent l'état de l'objet, ca affectera aussi la variable externe puisque c'est l'objet pointé qui est modifié !

ha oui
 
et donc si dans ça methode il faisait unObjetNonImmuable = autreInstance en sortie, il se retrouverait quand meme avec l'ancienne instance?

alloooooo stackframe, passage de paramètres, tout ça ...

oui

mais t'as fumé quoi aujourd'hui toi ?

ça va n'insistez pas

 
?