[gl-como] Tecniche di programmazione: break e continue
Pirla
the.pirla@flashnet.it
Mer 2 Mar 2005 21:36:49 CET
Il mar, 2005-03-01 alle 17:59, Scripter ha scritto:
> Oggi la mia prof di info mi ha fatto la ramanzina perché nella verifica ho
> usato 3 break per interrompere i cicli. Stessa cosa per i continue.
> Ma sono estremamente dannosi o se ci sono in tutti i linguaggi di
> programmazione di tutti i tempi c'è un motivo?
>
Ciao,
dopo aver letto tutti i reply al tuo messaggio ho deciso di rispondere
qui. Mi sembra il punto più importante.
Io non sono un "esperto programmatore" ma ho studiato molto, soprattutto
algoritmi.
L'informatica è basata su tanta tanta teoria.
E anche i linguaggi di programmazione si basano su molta teoria.
Praticamente tutti gli algoritmi (questo lo dice la teoria e io non sono
in grado di confutarlo) possono essere scritti indifferentemente nello
stesso linguaggio strutturato, con o senza salti incondizionati.
E' solo da intendere cosa è un salto incondizionato.
Alcuni dicono che break e simili non sono salti incondizionati (dato che
rispondono comunque ad una condizione e non ti portano fuori dal ciclo)
mentre altri affermano il contrario.
Il tutto è da inquadrare nell'ottica della leggibilità del programma ma
soprattutto della sua complessità finale.
Tieni presente che comunque il tuo programma verrà compilato in un
codice (molto probabilmente codice macchina) che farà uso di centinaia
di migliaia di salti per tradurre il tuo programmino di una decina di
righe.
E' però vero (e io in questo senso mi sento di appoggiare la tua prof)
che scrivere uno stesso programma (o algoritmo) senza l'uso di soluzioni
"poco eleganti" è un esercizio mentale molto proficuo.
Se sei in grado di vedere un altro modo di scrivere lo stesso codice
allora sei in grado di valutare quale delle due o tre o cento soluzioni
è la migliore.
A questo proposito faccio solo un esempio non usando un linguaggio ma
usando il linguaggio naturale.
Supponiamo di dover leggere un file e di interpretare ogni riga del file
di testo, e supponiamo anche che l'interpretazione di ogni riga rientra
in 5 condizioni esprimibili ognna con una IF.
Supponiamo anche che ogni condizione ha la stessa probabilità di tutte
le altre di verificarsi.
1^ ipotesi
ciclo while per leggere una riga
{
IF (condiz1)
{
fai qualcosa
}
ELSEIF (condiz2)
{
fai qualcosa
}
ELSEIF (condiz3)
{
fai qualcosa
}
ELSEIF (condiz4)
{
fai qualcosa
}
ELSEIF (condiz5)
{
fai qualcosa
}
}
In questo caso verranno eseguite molte IF inutili se mi trovo nella
condiz5.
Se scrivo la stessa cosa in questo modo:
ciclo while per leggere una riga
{
IF (condiz1)
{
fai qualcosa
continue; (salta all'ultima istruzione del ciclo while)
}
IF (condiz2)
{
fai qualcosa
continue; (salta all'ultima istruzione del ciclo while)
}
IF (condiz3)
{
fai qualcosa
continue; (salta all'ultima istruzione del ciclo while)
}
IF (condiz4)
{
fai qualcosa
continue; (salta all'ultima istruzione del ciclo while)
}
IF (condiz5)
{
fai qualcosa
continue; (salta all'ultima istruzione del ciclo while)
}
}
Ho usato un costrutto leggittimo come il continue, non elegante, che mi
spezza il flusso logico, ma che SOPRATTUTTO non mi ha dato nessun
vantaggio computazionale dato che il numero di IF da eseguire è lo
stesso nei due casi.
Ci sono invece dei casi in cui l'uso del modificatore di flusso è
vantagioso (soprattutto perché mi sto accorgendo di un baco nel flusso e
non so come correggerlo) dal punto di vista computazionale, o dal punto
di vista delle modifiche richieste. Molte volte dopo aver costruito il
ciclo una piccola modifica potrebbe richiedere la completa riscrittura
del ciclo con conseguente perdita di tempo.
Per concludere, secondo me la tua prof ha ragione a bacchettarti un po'
perché è importante a scuola applicare molto la teoria. Per la pratica e
i trucchetti c'è sempre tempo... L'importante è imparare bene.
--
Ciao
Pirla
Per rispondere in E-mail the (punto) pirla (chiocciola) flashnet.it
*** un bacio ai pupi ***
---> Linux user since yesterday <---
Maggiori informazioni sulla lista
gl-como