Pourquoi instancier une classe String ?

Bonjour,

Quelle différence entre déclarer une "variable" de type String de cette façon :

String maVariable = "niania";

Et l'instancier (sinon pour bénéficier des méthodes non static) ?

String maVariable = new String("nianiania");

Merci pour votre réponse !

Bonjour,
je t'invite à lire cet article (encore une fois) très intéressant tu y trouveras tes réponses :ccool:

jojodu31

Citation:

---

Envoyé par Thoustra

(sinon pour bénéficier des méthodes non static) ?

---

"nianiania" a parfaitement accès aux méthodes d'instance de String. Inutile de faire new String() pour ça.

Citation:

---

Envoyé par thelvin

"nianiania" a parfaitement accès aux méthodes d'instance de String. Inutile de faire new String() pour ça.

---

Je pose la question parce que je ne comprends pas un truc simple

Voyez :

Je récupère une donnée de 11 cars dans refFlux

elle s'affiche correctement, mais dès que je lui applique la méthode substring

elle n'affiche plus rien.

Code:

---

1 2 3 4 5 6

String refFlux = liste.getReferenceFlux(); System.out.println("refflux :" + refFlux); String val = (refFlux.substring(3, 3));   System.out.println("VAL : " + val);

---

résultat :

refflux :RDEIDEMWT21
VAL :

Devinette : qu'est-ce que le deuxième paramètre de substring() ?
C'est l'index du caractère où la substring doit s'arrêter, exclusivement.

donc, refFlux.substring(3, 3) => prendre la sous-string qui commence à l'index 3 et s'arrête avant l'index 3.
On appelle ça la chaîne vide, on peut la noter directement ""

Penser à lire la JavaDoc des méthodes qu'on utilise, avant de les utiliser.

Je suppose que tu voulais faire ça : refFlux.substring(3, 6)

Citation:

---

Envoyé par thelvin

Devinette : qu'est-ce que le deuxième paramètre de substring() ?
C'est l'index du caractère où la substring doit s'arrêter, exclusivement.

donc, refFlux.substring(3, 3) => prendre la sous-string qui commence à l'index 3 et s'arrête avant l'index 3.
On appelle ça la chaîne vide, on peut la noter directement ""

Penser à lire la JavaDoc des méthodes qu'on utilise, avant de les utiliser.

Je suppose que tu voulais faire ça : refFlux.substring(3, 6)

---

Désolé...:lol:

pour d'autres langages le second paramètre signifie la longueur du substring, j'aurai dû effectivement lire plus attentivement (car lue !) la java doc.

Dire que j'ai plongé dans des explications plus complexe (constructeurs de la classe String etc).

Note au passage que je préfère la convention des autres langages, qui me semble plus répandue... Mais la JavaDoc est tellement bien faite, quand on se pose une question c'est le premier endroit à consulter.

Citation:

---

Envoyé par Thoustra

pour d'autres langages le second paramètre signifie la longueur du substring, j'aurai dû effectivement lire plus attentivement (car lue !) la java doc.

---

C'est le piège amusant pour les gens qui ont fait du .Net :)

Puisqu'on en parle, je me demandais.
Quel est le comportement de ceci ?

Code:

---

String a = b.substring(0, 1) + c.substring(0, 1);

---

Y a-t-il création implicite d'un nouvel objet ?

En fait il y a une création de 4 objets !

Chaque appel à substring() génère un nouvel objet String.
Toutefois ce dernier partage le même buffer que le String original : seul ses index changent...

Donc tes deux substring() génère chacun un nouvel objet.


Les deux objets supplémentaires sont généré par l'opérateur +.
Comme les String sont immuables, la concaténation de chaine via cet opérateur passe en fait via la classe StringBuilder, et le code a + b est en fait convertie en new StringBuilder().append(a).append(b).toString(), ce qui donne dans ton cas :

Code:

---

1 2 3 4

String a = new StringBuilder() // Création d'un objet StringBuilder .append(b.substring(0, 1)) // Création d'un objet String .append(c.substring(0, 1)) // Création d'un objet String .toString(); // Création d'un objet String à partir du StringBuilder

---

a++

PS : Avant Java 5.0, les concaténations utilisaient la classe StringBuffer (même chose mais synchronisé).

Citation:

---

Envoyé par adiGuba

PS : Avant Java 5.0, les concaténations utilisaient la classe StringBuffer (même chose mais synchronisé).

---

Il faut même encore utiliser StringBuffer en multithreading, StringBuilder est plus rapide mais uniquement pour du simple thread.

Citation:

---

Envoyé par Jimmy_

Il faut même encore utiliser StringBuffer en multithreading, StringBuilder est plus rapide mais uniquement pour du simple thread.

---

En même temps je sais pas si tu concatènes souvent dans un même buffer avec des threads différents, mais moi j'en ai pas souvent l'usage.

Mais dans l'absolu c'est vrai, oui.

sans compter que les objets temporaires créés par l'opérateur de concaténation ne pourront de toutes façons, pour des raison évidentes jamais être partagés entre plusieurs thread => la création par java de stringbuilder depuis java 5 puisqu'il n'y a aucun besoin de protéger par des synchronized ;-)

Et oui, en 5 ans de carrière java, JAMAIS, je n'ai eu besoin de faire une concaténation sur plusieurs threads en // :mrgreen:

Voilà plus de détails que je n'en attendais, merci !

Oui c'est particulier, mais je suis sur un projet multithread qui justement a besoin des StringBuffer et par habitude on n'utilise jamais les StringBuilder.
On a 4 process Unix qui tournent ensemble et chacun peut déclancher jusqu'a 16 threads. Quand un user fait une grosse requête on dispatch tout ça pour aller le plus vite possible. Il faut bien recoller les morceaux une fois que tout le monde a fini :)

@Jimmy_ : tu manipules vraiment un même StringBuffer depuis plusieurs threads !?

a++

Oui le but est d'envoyer plein de requête en même temps.

Par curiosité : c'est quoi comme appli ? Tu en fait quoi de ton StringBuffer ?

a++

Citation:

---

Envoyé par adiGuba

Par curiosité : c'est quoi comme appli ? Tu en fait quoi de ton StringBuffer ?

a++

---

C'est un produit pour la finance , le temps de réponse est critique, on attaque des bases Oracles sur des serveurs mutualisés. Il y a des StringBuffers qui récupèrent les données des threads qui ont réussit a récupérer leur résultat.
Comme toujours avec Java, il y a des tonnes de truc qu'on utlise jamais , mais un jour ça sert ... :)

oui donc les cas d'usage sont donc limites. Puisque de toutes facons, stringbuffer ne fait que garantir la durabilité en multi thread, quand plusieurs thread écrivent, ca reste quand même écrit dans n'importe quel ordre :mouarf:, donc l'usage reste limité aux cas où on peut se permetre un ordre quelconque.

Citation:

---

Envoyé par tchize_

stringbuffer ne fait que garantir la durabilité en multi thread, quand plusieurs thread écrivent, ca reste quand même écrit dans n'importe quel ordre :mouarf:, donc l'usage reste limité aux cas où on peut se permetre un ordre quelconque.

---

Oui et c'est pour cela que je suis étonné de voir l'utilisation de StringBuffer en multithread sans synchronisation externe...

a++