Bonjour, je voudrait reécire une méthode toString, mais cell-ci renvoi un string avec des saut de ligne.  
 

 
Comme je voudrais éviter "\n" qui, il me semble, n'est pas portable sur tout les systeme, il me faudrait un moyen pour le remplacer de maniere portable.
 
Merci

Ptin mais
 
1- http://www.justfuckinggoogleit.com [...] va+newline
2- Faut utiliser un StringBuffer/StringBuilder quand tu fais des concaténations de strings, c'est fait pour ça.

Ok. merci pour la réponse.
 
Par contre, j'ai dus mal à comprendre pourquoi utilisé StringBuffer et WriteBuffer (où il est écrit "which can then be used to construct a string" ) plutot que String et concat.  
 
Pour google, j'ai essayé de faire mes recherche, mais j'utilisé pas le bon mot clef; erreur de débutant.

 
Parce que les String sont des objets immuables. C'est à dire qu'a chaque fois que tu fais une concatenation de 2 strings, ça va en instancier une 3ème.
 

 
donc lorsqu'on a besoin d'une chaine qui doit être mise à jour souvent dans une application, on gagne en ressources d'utiliser StringBuffer ou autres plutôt que String, c'est ça ?

Oui, surtout si cette chaine est construite par concatenation
 
ex :

Nombre de création d'instances de String => 19
Successivement en mémoire on aura les String suivantes de crées
"1", "2", "12", "3", "123", "4", "1234", "5", "12345", "6", "123456", "7", "1234567", "8", "123456789", "9", "123456789", "10", "12345678910" ...
 
Avec un StringBuffer maintenant :

  => 11 strings d'instanciées et 1 seul StringBuffer (on évite toutes les chaine intermédiaire en fait)
 
 
EDIT : Le principal inconvénient, c'est qu'on perd un peu en lisibilité du code

les String "intermédiaires" dues à la simple concaténation ne sont pas détruits par le GC ?

 
Je pense que si, mais il y a tout de même leur création qui prend de la ressource.
(C'est ça? (test pour savoir si j'ai bien suivit...))
 
Merci beaucoup Bidem!! Grace à toi, je me coucherai moins bête ce soir!  

Voila, comme expliqué par Bidem.
 
Sauf qu'il manque des morceaux, en bonus les dernières JVM utilisent StringBuilder en interne, mais ne sont pas assez "intelligentes" pour le placer à l'extérieur des boucles.
 
Résultat, l'exemple de Bidem avec une JVM 1.5 server serait intégralement convertie en StringBuffer, mais la fonction toString initiale serait compilée en un truc du genre:

public String toString() {
    String toString = new String();
    for(Iterator iter = listPoint.iterator(); iter.hasNext();) {
        StringBuilder temp = new StringBuilder(toString);
        temp.append((iter.next()).toString());
        temp.append("\n" );
        toString = temp.toString();
    }
    return toString;
}

(ça donnerait probablement pas exactement ce code, mais pas loin)
 
Résultat, création d'un String initial, création d'un StringBuffer à chaque itération, création d'un String à chaque itération (par StringBuffer.toString).
 
Ca fait beaucoup
 
Surtout quand on peut coder

public String toString() {
    StringBuffer output;
    for(Iterator iter = listPoint.iterator(); iter.hasNext();) {
        output.append((iter.next()).toString());
        output.append(System.getProperty("line.separator" ));
    }
    return output.toString;
}

 
C'est tout à fait ça, l'instanciation et le gc, n'ont pas un coût négrigeable  
 
Sinon, pour ta 1ère question : Cf Le tutorial Java est notre ami, il faut le regarder aussi   ("line.separator" ) EDIT : Grilled !

 
ok, tjs bon à savoir

Me semble que le GC de la JVM est un mark&sweep non
 
Donc son coût est quasi toujours négligeable, par contre l'instanciation ne l'est clairement pas

 
C'est moins une question d'"instanciation" ou de GC qu'une question générale de complexité. La complexité de buffer.append("1" ).append("2" )....append("n" ) est linéaire alors que celle de la concaténation buffer = "1" + "2" + ... + "n" est quadratique.
 
L'histoire d'instancier moins d'objets ou de donner moins de boulot au GC c'est des problèmes d'optimisations qui sont différent du fond du problème.

Hummm pas sûr du tout, pour moi les 2 sont linéaires.
 
buffer.append("1" ).append("2" )....append("n" ) => n appels de append impliquant (n + 1) objets
"1" + "2" + ... + "n" => (n - 1) concatenation, mais sur n + (n-1) objets
 
Mais peut être me trompe-je

 
Tu te trompes parce que l'énoncé est trompeur.
 
Le "n" ici représente dans le premier cas (avec "append" ) le nombre de caractère copiés, donc c'est linéaire.
 
En revanche, dans le deuxième cas il y a bien n-1 concaténations, mais la complexité d'une concaténation n'est certainement pas constante ! Elle est elle aussi linéaire. Finalement dans le deuxième cas on effectue 2+3+4+...+n copies de caractère, c'est à dire n(n+1)/2 - 1 copies en tout ce qui donne bien une complexité quadratique.

Ha oui, tiens t'as raison

mask>StringBUFFER en interne, pas builder. je crois
(Sbuilder n'est pas threadsafe)
 
HAHAHA A PART CA J4AI DIT UINE CONNERIE DONC J4EDITE COMME UIN POURCEAU

Ué bon s'possible c'est toi l'expert java pas moi  
(puis bon pour lui ça change rien quoi)