Newsgroup: it.comp.java
Titolo: Label e goto in java

Mi scuso per la domanda banale; ma come si realizza un salto mediante
label e goto in java?
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 label e goto in java?
Lascia perdere questo tipo di programmazione, e' orrenda, poco 
leggibile, poco strutturata e decisamente antiquata !

 label e goto in java?
break e/o continue.

 ha scritto nel
messaggio news:dqm602$fog$2...@area.cu.mi.it...

be no scusa quelle servono per interrompere un ciclo o
continuare dal passo successivo,
goto con label ti fa slatare proprio da un altra parte
all'interno di un metodo.

 all'interno di un metodo.
Già. Peccato però che non esista la keyword goto in java.
break e continue sono le istruzioni che possono riferirsi ad una label.

 ha scritto nel
messaggio news:dqmbcl$o2l$1...@area.cu.mi.it...

Si hai ragione, non le uso mai in tal senso, e mi ero
dimenticato il break etichettato

Gringo ha scritto:

Pero' cio' fa alquanto schifo !!!!!
lasciate perdere queste amenita'

 lasciate perdere queste amenita'
Ci sono casi limite nei quali fa piu' schifo non usarli.
Ad esempio:
for(int i = 0; i < n; ++i) {
  for(int j = 0; j < m; ++j) {
    for(int k = 0; k <  p; ++k) {
      if(test(k)) {
          //esci dai 3 cicli for..
      }
    }
  }
} 

 } 
In ogni modo non parlavo dei brak o dei continue in se, ma la 
possibilita' di simulare il "goto" ! ! !
ciao


leggi o rileggi quanto detto da Vincent Vega. 

 leggi o rileggi quanto detto da Vincent Vega. 
Il break etichettato e' qualche cosa di orribilmente poco strutturato e 
fa perdere la chiarezza e quindi la leggibilita' del codice.

Io farei una cosa tipo
boolean go = true;
for(int i = 0; i < n && go ; ++i) {
  for(int j = 0; j < m && go ; ++j) {
    for(int k = 0; k <  p && go ; ++k) {
      if(test(k)) {
          //esci dai 3 cicli for..
          go = false;
      }
    }
  }
A questo punto però viene da chiedere: ha senso usare un ciclo "for"
se poi in qualche caso si esce prima della fine "logica" del ciclo,
ovvero ad iterazioni completate ? Non andrebbe meglio un ciclo while,
almeno concettualmente ? Poi tutti d'accordo sul fatto che la
differenza pratica è ben poca...
In realtà mi porrei anche il problema del perchè mi trovo in una
situazione del genere... e dell'eventuale possibilità di progettare la
cosa in maniera diversa...

 ha scritto nel
messaggio
news:1137659353.6...@g43g2000cwa.googlegroups.com
..
.
Io farei una cosa tipo
In realtà mi porrei anche il problema del perchè mi trovo in
una
situazione del genere... e dell'eventuale possibilità di
progettare la
cosa in maniera diversa...
Secondo me il break e il continue sono utili nel loro
abituale uso, è la programmazione con i salti
che è deprecabile, ma ragazzi su queste cose ormai sono
stati addirittura stesi dei teoremi veri e propri,
i quali teoremi mostrano sia l'inefficienza dell'uso del
goto(break etichettato in java) per non parlare
dell'illeggibità pressochè totale dei programmi che
utlizzano
questa pratica di programmazione, la letteratura scientifica
ormai è chiara su questo punto: "l'uso dei salti è
deprecabile come 'pratica' di programmazione ma non l'uso
isolato"

> altra parte all'interno di un metodo.
VV> Già. Peccato però che non esista la keyword goto in java.
Ad essere precisini precisini la keyword esiste come parola riservata,
solo che usarla,  almeno col compilatore fornito con  la 1.4, manda in
errore...
E poi non parlerei così male del goto, anche se è come l'arsenico...
-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico  
\/		    e allevatore di bug da competizione

 perdere la chiarezza e quindi la leggibilita' del codice.
Tornando all'esempio sopra, cosa ti sembra piu' leggibile?
senza "goto"
boolean out = false;
for(int i = 0; i < n; ++i) {
  for(int j = 0; j < m; ++j) {
    for(int k = 0; k <  p; ++k) {
      if(test(k)) {
          out =true;
          break;
      }
      if(out) break;
    }
    if(out) break;
  }
}
oppure con i "goto"
esterno:
  for(int i = 0; i < n; ++i) {
   for(int j = 0; j < m; ++j) {
    for(int k = 0; k < p; ++k) {
     if(test(k)) {
       break esterno;
     }
    }
   }
  }
Sentiamo cosa ci guadagni con il primo esempio.
Devi dire che il secondo esempio ha questo e quel problema , e mostrare come 
l'uso degli "if break" risolve il problema... 


infatti in Java non vi sono i goto e i label.
I break e continue etichettati evitano gli aspetti negativi dei goto proprio 
perche' utilizzabili all'interno di cicli e basta.
Ci sono rari casi in cui possono tornare utili, quindi non vedo perche' 
essere totalmente prevenuti nei loro confronti.

 ha scritto nel messaggio
news:43cf670d$0$344$5fc...@news.tiscali.it...
| > questa pratica di programmazione, la letteratura
scientifica
| > ormai è chiara su questo punto: "l'uso dei salti è
| > deprecabile come 'pratica' di programmazione ma non
l'uso
| > isolato"
| >
| >
|
| infatti in Java non vi sono i goto e i label.
| I break e continue etichettati evitano gli aspetti
negativi dei goto proprio
| perche' utilizzabili all'interno di cicli e basta.
| Ci sono rari casi in cui possono tornare utili, quindi non
vedo perche'
| essere totalmente prevenuti nei loro confronti.
Non ho capito, in Java non c'è il goto ma c'è il break
etichettato, che alla fine ti fa programmare come il BASIC
se usato in modo intensivo all'interno di un metodo.
Ma se usato in modo parsimonioso può tornare utile, la
soluzione ottima non ce l'ha in mano nessuno, e quindi ben
venga
qualche soluzione estemporanea che ti risolve un
problema(vedi il break etichettato in java).

 sempre meglio che interrompere il ciclo
Interrompere un ciclo con un break non č affatto "il male". Anzi, č un
istruzione chiarissima. Si vede a colpo d'occhio cosa fa. Un
'assegnamennto forzato come quello da te suggerito č piů difficile da
vedere e notare e capire (poche frazioni di tempo, ma quando ti trovi a
mantenere progetti di una certa dimensione, magari scritti da altri,
vorresti non perderli proprio).
Poi non capisco... per i puristi che sputano sui break, č sbagliato
strutturare in quel modo il programma. Č sbagliata la semantica. Č
sbagliato uscire da un ciclo "anzitempo". Non č sbagliato il "modo".
-- 
L'idiozia trascende il mezzo con cui viene espressa.

 E poi non parlerei cosě male del goto, anche se č come l'arsenico...
Stai pensando anche tu a quello spezzone di codice a pagina 79 di UNP
vol 1 second edition di Stevens [ immagino ci fosse anche sulla prima
edizione, ma quella non la ho sottomano ]? (tanto per dirne uno...)


> l'arsenico...
EF> Stai pensando anche tu a quello spezzone di codice a pagina 79 di
EF> UNP vol 1 second edition di Stevens [ immagino ci fosse anche
EF> sulla prima edizione, ma quella non la ho sottomano ]? (tanto per
EF> dirne uno...)
Questo mi manca.
Sto pensando  ai molti automi che  mi č capitato di  vedere, al Duff's
device (valido solo in C e derivati e similia).
Mi passi qualche riferimento in piů ?
Grazie anticipatamente.


 Mi passi qualche riferimento in più ?
Unix Network Programming di Stevens Volume 1 Seconda Edizione, pagina
79. Devi andare tipo in una biblioteca. Su Amazon c'è la terza edizione
(cui io non ho accesso)
<
http://www.amazon.com/exec/obidos/tg/detail/-/0131411551/qid=1138015839
/sr=8-2/ref=pd_bbs_2/104-0061503-2962324?v=glance&s=books&n=507846>
Non so se lo trovi in giro, magari usato. La terza edizione non so se
c'è quel codicillo. In pratica quando definisce una "readline" che opera
su un socket, all'interno di un ciclo for usa un goto invece che
nestarci dentro un do_while. Tra l'altro è anche un uso parecchio
elegante, si legge bene [ la label è una decina di righe più sopra ]
etc. D'altra parte parliamo di Stevens


 writes:
EF> Unix Network Programming di Stevens Volume 1 Seconda Edizione,
EF> pagina 79.
Danke!
EF> D'altra parte parliamo di Stevens
Appunto, il goto è come l'arsenico.  In dosi minime al posto giusto ed
al momento giusto è un farmaco, altrimenti è un veleno.


 al momento giusto è un farmaco, altrimenti è un veleno.
Sarebbe da infilare nei fortune...
