perchè il goto è il male?

[blue_tech]

sì ma come ci si arriva allo switch?

se bisogna replicarlo allora va bene anche senza,
se ne serve uno allora ci si arriva, udite udite, con i goto

dipende dalla situazione... ad ogni modo nell'esempio stiamo lavorando sulla funzione ergo ci sarà una chiamata di funzione che ci porta allo switch...

torniamo sempre lì: ad alto livello, per ogni situazione, il goto è evitabile elegantemente senza dover per forza rinunciare alle prestazioni, manutenzione, ecc...

EDIT: che poi nell'esempio originale il goto serviva per saltare alle istruzioni degli errori... e abbiam mostrato come fosse possibile fare la stessa cosa senza goto... quello che viene prima di quel punto non ci è dato di saperlo giacchè manca il codice antecedente l'esempio... (esempio che poi è così generale che lascia spazio a varie interpretazioni ma sorvoliamo... )

[working_mad]

vabbe va, basta.
magari un giorno arriverete a dover implementare una logica del genere e capirete.

per adesso sta bene così. se siete contenti voi nella vostra ignoranza, figuratevi io

[Il Nero]

Faccio notare che la ragione per evitare il goto non è "Dio si arrabbia" ma "leggibilità e manutenibilità", e tutti gli esempi che avete fatto sono pesantemente meno leggibili dell'espressione con goto (se pensate il contrario siete banalmente in malafede, e ve lo dico io che non ho mai usato un goto, anche se adesso lo sto difendendo in linea di principio).

E' ovvio che c'è sempre un costrutto alternativo. Il problema è che se il costrutto alternativo è meno leggibile, allora è meglio goto, che è sostanzialmente sempre più veloce.

Ad esempio per fare la soluzione di blue_tech l'unica è fare una funzione dedicata o mettere il tutto in un blocco try ... catch, nel cui catch si vai poi a mettere lo switch. Peccato che la leggibilità è esattamente la medesima del goto se non peggiore e la velocità è inferiore. In particolare il costrutto switch senza i break è una merda ed è molto più illeggibile dei goto in fila, perchè è un uso "non tradizionale" (anche se frequente) dello switch.

L'esempio che facevo io è questo:

for(i = 0;...;...)
{
 for(j = 0;...;...)
 {
   for(k = 0;...;...)
    if (Array[i][j][k] == N) goto uscita
   //Operazioni che vogliamo fare se e solo se A[i][j][k] != N
  }
  //Operazioni che vogliamo fare se e solo se A[i][j][k] != N
}
uscita:

Certo si può risolvere mettendoci if (...) break all'uscita di ogni for. Peccato che come leggiblità e manutenibilità faccia cagare. E ridisegnare i for a volte fa ancora più cagare. Oppure mettere i loop annidati in una funzione ed usare return, così se ho una roba più complicata che comparare variabili base devo passare 24000 argomenti, o una struct-class apposita. E fa ancora più cagare.

[LordOrion]

vabbe va, basta.
magari un giorno arriverete a dover implementare una logica del genere e capirete.

per adesso sta bene così. se siete contenti voi nella vostra ignoranza, figuratevi io

Gia' fatto parecchie volte e mai usato il goto, non era necessario.

E' ovvio che c'è sempre un costrutto alternativo. Il problema è che se il costrutto alternativo è meno leggibile, allora è meglio goto, che è sostanzialmente sempre più veloce.

Ti sbagli: Guardati l'architettura e le istruzioni dei processori ARM e poi capirai perche'.

[Haruki]

for(i = 0;...;...)
{
 for(j = 0;...;...)
 {
   for(k = 0;...;...)
    if (Array[i][j][k] == N) goto uscita
   //Operazioni che vogliamo fare se e solo se A[i][j][k] != N
  }
  //Operazioni che vogliamo fare se e solo se A[i][j][k] != N
}
uscita:

checkarray(Array) {
for(i = 0;...;...)
{
 for(j = 0;...;...)
 {
   for(k = 0;...;...)
    if (Array[i][j][k] == N) return
   //Operazioni che vogliamo fare se e solo se A[i][j][k] != N
  }
  //Operazioni che vogliamo fare se e solo se A[i][j][k] != N
}
}

checkarray(Array)
//uscita

usiamo tutti il goto!

[Haruki]

sì ma come ci si arriva allo switch?

se bisogna replicarlo allora va bene anche senza,
se ne serve uno allora ci si arriva, udite udite, con i goto

int funz(....) {
    ....
    if (!(err=err1)) {
    ....
		if (!(err=err2)) {
		....
			if (!(err=err3)) {
			....
			}
		}
	}
	
	switch( err ) 
    {
		case err3:
			...
		case err2:
			...
		case err1:
			...
		break;
   }
   ...
   return rc;
}

il risultato di questo è paro paro spiaccicato al tuo esempio

[working_mad]

aaaaah questo sì che è leggibile
e veloce


non fate arrabbiare dio, per carità. non utilizzatelo MAI altrimenti verrete scomunicati

[Il Nero]

Ma perchè non leggete i post fino all'ultima riga ?

[Haruki]

aaaaah questo sì che è leggibile
e veloce


non fate arrabbiare dio, per carità. non utilizzatelo MAI altrimenti verrete scomunicati

Rallenta? Di un millisecondo? Rispetto al tuo codice c'è solo un condizionale in più, i 3 precedenti erano presenti anche nel tuo codice. Inoltre è leggibilissimo, sicuramente più del goto che ti rimanda chissà dove e chissà in che punto della pagina, mentre qui devi solo scorrere alla parentesi di chiusura dell'IF.

Ma perchè non leggete i post fino all'ultima riga ?

Nero, quando il codice si fa complicato da OBBLIGARTI a usare il goto per evitare di passare 24000 argomenti a una funzione, significa che come design quel codice fa cagare. Non so quanto ne andrei fiero.

Perché di questo si tratta, scelte di coding e design.

Ma ovviamente io, così come gli altri, siam visti come dei novellini non usando il goto, quindi le nostre idee fanno schifo a prescindere. Quindi che vuoi che ti dica? Però il mio punto di vista non posso non esternarlo.

[working_mad]

haruki legge una riga sì e una no dei post e fra tutte quelle che legge ne capisce un decimo

e poi fino a prova contraria siete stati voi detrattori che avete dato dei novellini a noi fin dall'inizio del topic. Adesso non si sa bene perché hai rigirato completamente la frittata

Ah, se poi quel codice viene eseguito 100 volte in un secondo allora sì che si va VERAMENTE veloce
chissà poi dove rimanderà un diabolico goto in quella situazione . un pochetto più in giù nel codice.


Ma qui la domanda è: ti senti ancora di affermare che chi usa il goto in una situazione come questa non capisce un cazzo di programmazione? Se sì, beh, allora non hai capito un cazzo fondamentalmente, se no, bene, almeno hai dimostrato che la differenza fra te e un mulo non sta soltanto nell'avere la coda

[Haruki]

haruki legge una riga sì e una no dei post e fra tutte quelle che legge ne capisce un decimo

Ah, se poi quel codice viene eseguito 100 volte in un secondo allora sì che si va VERAMENTE veloce

quando il codice si fa complicato da OBBLIGARTI a usare il goto per evitare di passare 24000 argomenti a una funzione, significa che come design quel codice fa cagare. Non so quanto ne andrei fiero.

A quanto vedo, non sono il solo.

e poi fino a prova contraria siete stati voi detrattori che avete dato dei novellini a noi fin dall'inizio del topic. Adesso non si sa bene perché hai rigirato completamente la frittata

Non siamo NOI, è tutto il mondo conosciuto. Ci sono postille su ogni singolo libro di programmazione.

almeno hai dimostrato che la differenza fra te e un mulo non sta soltanto nell'avere la coda

Passiamo alle offese? Complimenti, bella maturità.

[Il Nero]

Nero, quando il codice si fa complicato da OBBLIGARTI a usare il goto per evitare di passare 24000 argomenti a una funzione, significa che come design quel codice fa cagare. Non so quanto ne andrei fiero.

A parte che quest'affermazione è discutibile, nel senso che a volte non c'è modo di evitare di passare numerosi argomenti, indipendentemente da quanto uno è bravo a fare "il design del codice" (es. calcolo di una funzione multi-variabile non-invertibile con argomento valori dell'array e valori esterni), ma soprassediamo.

Il punto è che la tua versione, se la funzione viene usata una sola volta (e verrà usata una sola volta, altrimenti non sarebbe stato conveniente dall'inizio farla col goto), in realtà è MENO leggibile della versione con il goto, quindi a parte "eh figata, non ci ho messo il goto", non c'è alcuna ragione per preferirla alla versione con il goto.

[Sticky©]

Tutto ciò è molto

Chiudo, tanto non si arriverà a un punto comune e soprattutto c'è qualcuno che non riesce ad avere una discussione civile, manco fossimo in Backstage o Bar Sport.

Felice di fare il sistemista.