Newsgroup: it.comp.java
Titolo: reverse

Salve,
non esiste un metodo che restituisce l'inversa di una stringa data?
Grazie
--
Noixe

 non esiste un metodo che restituisce l'inversa di una stringa data?
Non credo, ma non è molto difficile farla!
public String reverse(String s) {
    String reverseString = "";
    for(int i=s.lenght();i>=0;i--) {
        reverseString+=s.charAt(i);
    }
    return reverseString;
}
Ciao!
--
Marco "Duff" Palermo
http://www.marcoduff.com/

 
StringBuffer.reverse()
-- 
Lucio Benfante
Java User Group Padova: 
http://www.jugpadova.it
Brainbench MVP for Java 1: 
http://www.brainbench.com
MyTranscript: 
http://www.brainbench.com/transcript.jsp?pid=167064

 }
Mi sono sempre chiesto se il compilatore java in questo caso riesce ad 
ottimizzare e utilizzare uno StringBuffer o se crea ogni volta una nuova 
stringa.
In quest'ultimo caso il tuo suggerimento e' quanto di piu' inefficiente 
si possa pensare.
Per copiare una stringa di n caratteri crei n stringhe di lunghezza 
crescente da 0 a n, ogni volta copiando quella precedente e aggiungendo 
un carattere.
Andrea

 un carattere.
Esatto.
Anzi, per essere precisi è una divergenza esponenziale.
Il problema sta nella filosofia che ci metti dietro...
Ok, questo esempio è banale, ma può valere come regola generale.
Chi vuole un programma ottimizzato, pronto e rapido non si mette ad 
usare neanche per sbaglio la classe String, va subito alla StringBuffer.
Anzi, mi permetto di dire, che chi vuole un programma ottimizzato, 
pronto e rapido non tiene in considerazione neanche Java come linguaggio!
Io capisco che si deve sempre mirare al massimo, ma i tempi 
dell'Assembler sono passati, non ci si può più porre il problema di aver 
lasciato un buco di 32 byte in memorie da 512 MB!
Quello che voglio dire è questo:
probabilmente chi si crea il problema di invertire una stringa non è 
ancora pronto per passi grossi nel linguaggio, ed il primo "Hello World" 
si fa con una String.
Nel momento in cui una persona diventa più pratica con il linguaggio si 
troverà d'avanti un applicativo che ci sta 3 secondi per elaborare una 
stringa e in quel momento capirà di aver sbagliato qualche cosa e 
tornerà all'ottimizzazione del codice.
IMHO chi programma in java non deve avere immediatamente la testa a 
rendere il codice velocissimo, perchè ha sbagliato linguaggio!
Credo di stare parlando con una persona che capisce che la scelta di un 
linguaggio di programmazione non si fa per moda...


 linguaggio di programmazione non si fa per moda...
Sono daccordo che non si deve essere ossessionati dall'ottimizzazione 
mentre si programma. E' assurdo "fare la punta ai bit" come diceva il 
mio Professore di Sistemi 1, e se si hanno necessita' estreme java non 
e' decisamente il linguaggio adatto.
Pero' e' bene acquisire alcune buoni abitudini che fanno in modo che si 
produca codice "moderatamente" ottimizzato senza troppo sforzo.
Ad esempio evitare di concatenare direttamente le stringhe all'interno 
di un ciclo che potrebbe essere molto lungo.
Poi se devo concatenare 3/4 stringhe ovvio non mi metto li a creare uno 
StringBuffer.
Andrea Polci

 produca codice "moderatamente" ottimizzato senza troppo sforzo.
Siamo d'accordo.
Io metterei l'Hello World in una StringBuffer, ma sono coscente che la 
Classe StringBuffer l'ho conosciuta MOLTO dopo la classe String!
Il problema è, secondo il mio punto di vista, che per capite l'utilità 
di StringBuffer bisogna prima sbattere la faccia su String.
Ma soprattutto, capire "il perchè" usare StringBuffer è meglio che usare 
String, è un concetto non proprio alla portata di tutti...


 Crea una nuova stringa (con uguale riferimento).
Uh? Non dovrebbe: quello e' una caso da manuale in cui anche un 
compilatore minimamente sveglio puo' sostituire StringBuffer: un
riferimento a String inizializzato fuori da un ciclo e aumentato con +=.
Anche una rudimentale flow analysis si accorge che le stringhe
intermedie non servono a niente e puo' ottimizzare. 
Compilando con il javac di Sun infatti il bytecode usa StringBuffer
(1.4.2_03).
-- 
You dont know what to do when you dont know what you're doing.
http://space.tin.it/computer/csadun

 (1.4.2_03).
Prova questo codice:
public class StringOrBuffer {
	public static void main(String[] argv) {
		long time;
 
		String s = new String();
		time = System.currentTimeMillis();
		System.out.println("Starting String Test...");
		for(int i=0;i<30000;i++)
			s+="a";
		System.out.println("Starting String Test Time: 
"+(System.currentTimeMillis()-time)+"ms");
 
		StringBuffer sb = new StringBuffer();
		time = System.currentTimeMillis();
		System.out.println("Starting StringBuffer Test...");
		for(int i=0;i<30000;i++)
			sb.append("a");
		System.out.println("Starting StringBuffer Test Time: 
"+(System.currentTimeMillis()-time)+"ms");		
	}
}
Nel mio PC (SDK 1.4.1_02) l'output è il seguente:
Starting String Test...
Starting String Test Time: 11296ms
Starting StringBuffer Test...
Starting StringBuffer Test Time: 0ms
Riprendo il discorso di prima: chi ha fatto il Linguaggio (e di 
conseguenza il compilatore) non ha messo tra le priorità la velocità di 
esecuzione.


 
Hai ragione. javac invoca toString() sul risultato per riassegnarlo ad s ad 
ogni iterazione. :(
