È mai vantaggioso usare 'goto' in un linguaggio che supporta loop e funzioni? Se è così, perché?

Sono stato a lungo sotto l'impressione che gotonon dovrebbe mai essere usato se possibile. Mentre guardavo libavcodec (che è scritto in C) l'altro giorno, ho notato molteplici usi di esso. È mai vantaggioso utilizzare gotoin un linguaggio che supporta loop e funzioni? Se è così, perché?

Ci sono alcuni motivi per usare la frase "goto" di cui sono a conoscenza (alcuni ne hanno già parlato):

Uscire in modo pulito da una funzione

Spesso in una funzione, è possibile allocare risorse e dover uscire in più punti. I programmatori possono semplificare il loro codice inserendo il codice di pulizia delle risorse alla fine della funzione e tutti i "punti di uscita" della funzione passerebbero all'etichetta di pulizia. In questo modo, non è necessario scrivere il codice di pulizia in ogni "punto di uscita" della funzione.

Uscita da loop nidificati

Se sei in un ciclo nidificato e devi uscire da tutti i loop, un goto può renderlo molto più pulito e più semplice delle dichiarazioni di interruzione e degli if-check.

Miglioramenti delle prestazioni di basso livello

Questo è valido solo nel codice perf-critico, ma le istruzioni goto vengono eseguite molto rapidamente e possono darti una spinta quando ti muovi attraverso una funzione. Questa è un'arma a doppio taglio, perché un compilatore in genere non può ottimizzare il codice che contiene gotos.

Si noti che in tutti questi esempi, i gotos sono limitati all'ambito di una singola funzione.

Chiunque sia contrario goto, direttamente o indirettamente, all'articolo GoTo considerato dannoso di Edsger Dijkstra a sostegno della propria posizione. Peccato che l'articolo di Dijkstra non abbia praticamente nulla a che fare con il modo in cui le gotodichiarazioni sono usate in questi giorni e quindi ciò che dice l'articolo ha poca o nessuna applicabilità alla moderna scena della programmazione. Il gotomeme senza-orlo ora punta su una religione, fino alle sue scritture dettate dall'alto, i suoi sommi sacerdoti e lo schianto (o peggio) degli eretici percepiti.

Mettiamo il contesto di Dijkstra nel contesto per fare un po 'di luce sull'argomento.

Quando Dijkstra scrisse il suo articolo le lingue popolari dell'epoca erano quelle procedurali non strutturate come BASIC, FORTRAN (i dialetti precedenti) e varie lingue assembleari. Era abbastanza comune per le persone che usano le lingue di livello superiore saltare tutta la loro base di codice in fili contorti e contorti di esecuzione che hanno dato origine al termine "codice spaghetti". Puoi vederlo saltando al classico gioco Trek scritto da Mike Mayfield e cercando di capire come funzionano le cose. Prenditi qualche momento per guardarlo.

QUESTO è "l'uso sfrenato della dichiarazione go to" contro cui Dijkstra stava recitando nel suo documento nel 1968. Questo è l'ambiente in cui viveva che lo ha portato a scrivere quel documento. La capacità di saltare ovunque nel tuo codice in qualsiasi momento ti piacesse era ciò che stava criticando e chiedendo di essere fermato. Confrontandolo con i poteri anemici digoto in C o di altri linguaggi così più moderni è semplicemente risibile.

Posso già sentire i canti sollevati dei cultisti mentre affrontano l'eretico. "Ma" canteranno "puoi rendere il codice molto difficile da leggere gotoin C." O si? Puoi anche rendere il codice molto difficile da leggere senza goto. Come questo:

#define _ -F<00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()
{
            _-_-_-_
       _-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
        _-_-_-_-_-_-_-_
            _-_-_-_
}

Non uno gotoin vista, quindi deve essere facile da leggere, giusto? O che ne pensi di questo:

a[900];     b;c;d=1     ;e=1;f;     g;h;O;      main(k,
l)char*     *l;{g=      atoi(*      ++l);       for(k=
0;k*k<      g;b=k       ++>>1)      ;for(h=     0;h*h<=
g;++h);     --h;c=(     (h+=g>h     *(h+1))     -1)>>1;
while(d     <=g){       ++O;for     (f=0;f<     O&&d<=g
;++f)a[     b<<5|c]     =d++,b+=    e;for(      f=0;f<O
&&d<=g;     ++f)a[b     <<5|c]=     d++,c+=     e;e= -e
;}for(c     =0;c<h;     ++c){       for(b=0     ;b<k;++
b){if(b     <k/2)a[     b<<5|c]     ^=a[(k      -(b+1))
<<5|c]^=    a[b<<5      |c]^=a[     (k-(b+1     ))<<5|c]
;printf(    a[b<<5|c    ]?"%-4d"    :"    "     ,a[b<<5
|c]);}      putchar(    '\n');}}    /*Mike      Laman*/

Neanche gotolì. Deve quindi essere leggibile.

Qual è il mio punto con questi esempi? Non sono le funzionalità linguistiche che rendono il codice illeggibile e non realizzabile. Non è la sintassi che lo fa. Sono i cattivi programmatori a causare questo. E i cattivi programmatori, come puoi vedere nell'elemento sopra, possono rendere illeggibile e inutilizzabile qualsiasi lingua. Come i forloop lassù. (Li vedi, vero?)

Ora, per essere onesti, alcuni costrutti linguistici sono più facili da abusare di altri. Se sei un programmatore C, scruterei molto più da vicino circa il 50% degli usi di #definemolto prima di andare contro una crociata goto!

Quindi, per coloro che si sono presi la briga di leggere così lontano, ci sono diversi punti chiave da notare.

1. Il documento di Dijkstra sulle gotodichiarazioni è stato scritto per un ambiente di programmazione in cui gotoera molto più potenzialmente dannoso di quanto non lo sia nella maggior parte dei linguaggi moderni che non sono un assemblatore.
2. Eliminando automaticamente tutti gli usi di goto per questo è razionale quanto dire "Ho provato a divertirmi una volta ma non mi è piaciuto, quindi ora sono contrario".
3. Ci sono usi legittimi del moderno (anemico) goto dichiarazioni nel codice che non possono essere adeguatamente sostituite da altri costrutti.
4. Vi sono, ovviamente, usi illegittimi delle stesse dichiarazioni.
5. Ci sono anche usi illegittimi delle moderne dichiarazioni di controllo come l '" godo" abominio in cui un dociclo sempre falso viene interrotto dall'uso breakal posto di un goto. Questi sono spesso peggiori dell'uso giudizioso di goto.

Obbedire alle migliori pratiche alla cieca non è una buona pratica. L'idea di evitare gotoaffermazioni come forma primaria di controllo del flusso è quella di evitare la produzione di codice spaghetti illeggibile. Se usati con parsimonia nei posti giusti, a volte possono essere il modo più semplice e chiaro di esprimere un'idea. Walter Bright, il creatore del compilatore C ++ di Zortech e del linguaggio di programmazione D, li usa frequentemente, ma con giudizio. Anche con le gotodichiarazioni, il suo codice è ancora perfettamente leggibile.

In conclusione: evitare gotoper il gusto di evitare gotoè inutile. Quello che vuoi veramente evitare è la produzione di codice illeggibile. Se il tuo gotocodice -laden è leggibile, non c'è nulla di sbagliato in esso.

Dal momento che gotorende difficile il ragionamento sul flusso di programma ¹ (alias "spaghetti code"), gotoviene generalmente utilizzato solo per compensare le funzioni mancanti: l'uso di gotopuò effettivamente essere accettabile, ma solo se la lingua non offre una variante più strutturata per ottenere lo stesso obiettivo. Prendi l'esempio del dubbio:

La regola con goto che usiamo è che goto va bene per saltare in avanti verso un singolo punto di pulizia di uscita in una funzione.

Questo è vero, ma solo se la lingua non consente la gestione strutturata delle eccezioni con il codice di pulizia (come RAII o finally ), che fa lo stesso lavoro meglio (poiché è appositamente progettato per farlo), o quando c'è una buona ragione per non utilizzare la gestione delle eccezioni strutturata (ma non si avrà mai questo caso se non a un livello molto basso).

Nella maggior parte delle altre lingue, l'unico uso accettabile di gotoè di uscire da loop nidificati. E anche lì è quasi sempre meglio sollevare il circuito esterno in un proprio metodo e utilizzare returninvece.

A parte questo, gotoè un segno che non è stato pensato abbastanza nel particolare pezzo di codice.

¹ I linguaggi moderni che supportano l' gotoimplementazione di alcune restrizioni (ad esempio gotopotrebbero non entrare o uscire dalle funzioni) ma il problema rimane sostanzialmente lo stesso.

Per inciso, lo stesso vale ovviamente anche per le altre funzionalità linguistiche, in particolare le eccezioni. E di solito esistono regole rigide per usare queste funzionalità solo dove indicato, come la regola di non usare eccezioni per controllare un flusso di programmi non eccezionale.

Bene, c'è una cosa che è sempre peggio di goto's; strano uso di altri operatori del flusso di programma per evitare un goto:

Esempi:

    // 1
    try{
      ...
      throw NoErrorException;
      ...
    } catch (const NoErrorException& noe){
      // This is the worst
    } 


    // 2
    do {
      ...break; 
      ...break;
    } while (false);


    // 3
    for(int i = 0;...) { 
      bool restartOuter = false;
      for (int j = 0;...) {
        if (...)
          restartOuter = true;
      if (restartOuter) {
        i = -1;
      }
    }

etc
etc

In C # interruttore dichiarazione fai non permettere caduta-through . Quindi goto viene utilizzato per trasferire il controllo a un'etichetta specifica per la custodia o l' impostazione predefinita all'etichetta .

Per esempio:

switch(value)
{
  case 0:
    Console.Writeln("In case 0");
    goto case 1;
  case 1:
    Console.Writeln("In case 1");
    goto case 2;
  case 2:
    Console.Writeln("In case 2");
    goto default;
  default:
    Console.Writeln("In default");
    break;
}

Modifica: esiste un'eccezione alla regola "nessun fall-through". Fall-through è consentito se un'istruzione case non ha codice.

#ifdef TONGUE_IN_CHEEK

Perl ha un gotoche ti permette di implementare le chiamate di coda dei poveri. :-P

sub factorial {
    my ($n, $acc) = (@_, 1);
    return $acc if $n < 1;
    @_ = ($n - 1, $acc * $n);
    goto &factorial;
}

#endif

Va bene, quindi non ha nulla a che fare con C's goto. Più seriamente, sono d'accordo con gli altri commenti sull'utilizzo gotoper le pulizie, o per l'implementazione del dispositivo di Duff o simili. Si tratta solo di usare, non di abusare.

(Lo stesso commento può essere applicato a longjmpeccezioni call/cce simili --- hanno usi legittimi, ma possono essere facilmente abusati. Ad esempio, lanciare un'eccezione puramente per sfuggire a una struttura di controllo profondamente annidata, in circostanze completamente non eccezionali .)

Nel corso degli anni ho scritto più di poche righe di linguaggio assembly. Alla fine, ogni linguaggio di alto livello si compila in goto. Va bene, chiamali "rami" o "salti" o qualsiasi altra cosa, ma sono goto. Qualcuno può scrivere assembler goto-less?

Ora certo, puoi indicare a un programmatore Fortran, C o BASIC che eseguire una rivolta con goto è una ricetta per spaghetti alla bolognese. La risposta però non è evitarli, ma usarli con cura.

Un coltello può essere usato per preparare cibo, liberare qualcuno o uccidere qualcuno. Facciamo senza coltelli per paura di quest'ultimo? Allo stesso modo il goto: usato con noncuranza ostacola, usato con cura aiuta.

Dai un'occhiata a Quando usare Goto durante la programmazione in C :

Sebbene l'uso di goto sia quasi sempre una cattiva pratica di programmazione (sicuramente puoi trovare un modo migliore di fare XYZ), ci sono momenti in cui non è davvero una cattiva scelta. Alcuni potrebbero persino sostenere che, quando è utile, è la scelta migliore.

La maggior parte di ciò che ho da dire su goto si applica in realtà solo a C. Se stai usando C ++, non c'è motivo valido per usare goto al posto delle eccezioni. In C, tuttavia, non hai la potenza di un meccanismo di gestione delle eccezioni, quindi se desideri separare la gestione degli errori dal resto della logica del programma e vuoi evitare di riscrivere il codice di pulizia più volte nel codice, allora goto può essere una buona scelta.

Cosa voglio dire? Potresti avere un codice simile al seguente:

int big_function()
{
    /* do some work */
    if([error])
    {
        /* clean up*/
        return [error];
    }
    /* do some more work */
    if([error])
    {
        /* clean up*/
        return [error];
    }
    /* do some more work */
    if([error])
    {
        /* clean up*/
        return [error];
    }
    /* do some more work */
    if([error])
    {
        /* clean up*/
        return [error];
    }
    /* clean up*/
    return [success];
}

Questo va bene fino a quando non ti rendi conto che è necessario modificare il codice di pulizia. Quindi devi passare e apportare 4 modifiche. Ora, potresti decidere che puoi semplicemente incapsulare tutta la pulizia in un'unica funzione; non è una cattiva idea. Ma significa che dovrai stare attento con i puntatori: se prevedi di liberare un puntatore nella tua funzione di pulizia, non c'è modo di impostarlo su NULL a meno che non passi un puntatore a un puntatore. In molti casi, non utilizzerai nuovamente quel puntatore, quindi potrebbe non essere un grosso problema. D'altra parte, se aggiungi un nuovo puntatore, un handle di file o altre cose che necessitano di pulizia, dovrai cambiare di nuovo la tua funzione di pulizia; e quindi dovrai cambiare gli argomenti in quella funzione.

Usando goto, lo sarà

int big_function()
{
    int ret_val = [success];
    /* do some work */
    if([error])
    {
        ret_val = [error];
        goto end;
    }
    /* do some more work */
    if([error])
    {
        ret_val = [error];
        goto end;
    }
    /* do some more work */
    if([error])
    {
        ret_val = [error];
        goto end;
    }
    /* do some more work */
    if([error])
    {
        ret_val = [error];
        goto end;
    }
end:
    /* clean up*/
    return ret_val;
}

Il vantaggio qui è che il codice che segue ha accesso a tutto ciò che sarà necessario per eseguire la pulizia e sei riuscito a ridurre considerevolmente il numero di punti di modifica. Un altro vantaggio è che sei passato dall'avere più punti di uscita per la tua funzione a uno solo; non c'è possibilità che tu possa tornare accidentalmente dalla funzione senza ripulire.

Inoltre, poiché goto viene utilizzato solo per saltare a un singolo punto, non è come se si stesse creando una massa di codice spaghetti saltando avanti e indietro nel tentativo di simulare le chiamate di funzione. Piuttosto, goto in realtà aiuta a scrivere codice più strutturato.

In una parola, gotodovrebbe sempre essere usato con parsimonia e come ultima risorsa - ma c'è un tempo e un posto per questo. La domanda non dovrebbe essere "devi usarla" ma "è la scelta migliore" per usarla.

Uno dei motivi per cui goto è male, oltre allo stile di codifica è che puoi usarlo per creare loop sovrapposti , ma non nidificati :

loop1:
  a
loop2:
  b
  if(cond1) goto loop1
  c
  if(cond2) goto loop2

Ciò creerebbe la struttura del flusso di controllo bizzarra, ma forse legale, in cui una sequenza come (a, b, c, b, a, b, a, b, ...) è possibile, il che rende infelici gli hacker del compilatore. Apparentemente ci sono una serie di trucchi di ottimizzazione intelligenti che si basano su questo tipo di struttura che non si verifica. (Dovrei controllare la mia copia del libro dei draghi ...) Il risultato di questo potrebbe (usando alcuni compilatori) essere che altre ottimizzazioni non sono fatte per il codice che contienegoto s.

Potrebbe essere utile se lo sai solo "oh, a proposito", capita di convincere il compilatore ad emettere codice più veloce. Personalmente, preferirei provare a spiegare al compilatore cosa è probabile e cosa no prima di usare un trucco come goto, ma probabilmente, potrei anche provare gotoprima di hackerare assemblatore.

Trovo divertente che alcune persone arrivino al punto di fornire un elenco di casi in cui goto è accettabile, dicendo che tutti gli altri usi sono inaccettabili. Pensi davvero di conoscere ogni caso in cui goto è la scelta migliore per esprimere un algoritmo?

Per illustrarti, ti faccio un esempio che nessuno qui ha ancora mostrato:

Oggi stavo scrivendo un codice per inserire un elemento in una tabella hash. La tabella hash è una cache di calcoli precedenti che possono essere sovrascritti a piacimento (influendo sulle prestazioni ma non sulla correttezza).

Ogni bucket della tabella hash ha 4 slot e ho un sacco di criteri per decidere quale elemento sovrascrivere quando un bucket è pieno. In questo momento questo significa fare fino a tre passaggi attraverso un secchio, in questo modo:

// Overwrite an element with same hash key if it exists
for (add_index=0; add_index < ELEMENTS_PER_BUCKET; add_index++)
  if (slot_p[add_index].hash_key == hash_key)
    goto add;

// Otherwise, find first empty element
for (add_index=0; add_index < ELEMENTS_PER_BUCKET; add_index++)
  if ((slot_p[add_index].type == TT_ELEMENT_EMPTY)
    goto add;

// Additional passes go here...

add:
// element is written to the hash table here

Se non usassi goto, come sarebbe questo codice?

Qualcosa come questo:

// Overwrite an element with same hash key if it exists
for (add_index=0; add_index < ELEMENTS_PER_BUCKET; add_index++)
  if (slot_p[add_index].hash_key == hash_key)
    break;

if (add_index >= ELEMENTS_PER_BUCKET) {
  // Otherwise, find first empty element
  for (add_index=0; add_index < ELEMENTS_PER_BUCKET; add_index++)
    if ((slot_p[add_index].type == TT_ELEMENT_EMPTY)
      break;
  if (add_index >= ELEMENTS_PER_BUCKET)
   // Additional passes go here (nested further)...
}

// element is written to the hash table here

Sembrerebbe sempre peggio se venissero aggiunti più passaggi, mentre la versione con goto mantiene sempre lo stesso livello di rientro ed evita l'uso di false istruzioni if ​​il cui risultato è implicito dall'esecuzione del ciclo precedente.

Quindi c'è un altro caso in cui goto rende il codice più pulito e più facile da scrivere e capire ... Sono sicuro che ce ne sono molti altri, quindi non far finta di conoscere tutti i casi in cui goto è utile, dissumando quelli buoni che non potresti non pensare.

La regola con goto che usiamo è che goto va bene per saltare in avanti verso un singolo punto di pulizia di uscita in una funzione. In funzioni davvero complesse rilassiamo questa regola per consentire altri salti in avanti. In entrambi i casi evitiamo istruzioni nidificate se spesso si verificano con il controllo del codice di errore, il che aiuta la leggibilità e la manutenzione.

La discussione più ponderata e approfondita delle dichiarazioni di goto, dei loro usi legittimi e dei costrutti alternativi che possono essere usati al posto di "dichiarazioni di goto virtuose" ma che possono essere abusate facilmente come le dichiarazioni di goto, è l'articolo di Donald Knuth " Programmazione strutturata con dichiarazioni di goto " , nel dicembre 1974 Computing Surveys (volume 6, n. 4. pp. 261 - 301).

Non sorprende che alcuni aspetti di questo documento di 39 anni siano datati: aumenti degli ordini di grandezza della potenza di elaborazione rendono alcuni dei miglioramenti delle prestazioni di Knuth impercettibili per problemi di dimensioni moderate, e da allora sono stati inventati nuovi costrutti del linguaggio di programmazione. (Ad esempio, i blocchi try-catch fanno parte del Construct di Zahn, sebbene vengano usati raramente in quel modo.) Ma Knuth copre tutti gli aspetti dell'argomento e dovrebbe essere richiesto di leggere prima che qualcuno ripeti nuovamente il problema.

In un modulo Perl, occasionalmente vuoi creare subroutine o chiusure al volo. Il fatto è che una volta creata la subroutine, come ci si arriva. Potresti semplicemente chiamarlo, ma se la subroutine lo utilizza caller()non sarà così utile come potrebbe essere. È qui che la goto &subroutinevariazione può essere utile.

Ecco un breve esempio:

sub AUTOLOAD{
  my($self) = @_;
  my $name = $AUTOLOAD;
  $name =~ s/.*:://;

  *{$name} = my($sub) = sub{
    # the body of the closure
  }

  goto $sub;

  # nothing after the goto will ever be executed.
}

È inoltre possibile utilizzare questo modulo gotoper fornire una forma rudimentale di ottimizzazione della coda.

sub factorial($){
  my($n,$tally) = (@_,1);

  return $tally if $n <= 1;

  $tally *= $n--;
  @_ = ($n,$tally);
  goto &factorial;
}

( Nel versione 16 di Perl 5 sarebbe meglio scrivere come goto __SUB__;)

C'è un modulo che importerà un tailmodificatore e uno che importerà recurse non ti piace usare questo modulo digoto .

use Sub::Call::Tail;
sub AUTOLOAD {
  ...
  tail &$sub( @_ );
}

use Sub::Call::Recur;
sub factorial($){
  my($n,$tally) = (@_,1);

  return $tally if $n <= 1;
  recur( $n-1, $tally * $n );
}

La maggior parte degli altri motivi per utilizzare gotosono fatti meglio con altre parole chiave.

Come redoun po 'di codice:

LABEL: ;
...
goto LABEL if $x;

{
  ...
  redo if $x;
}

O andando a lastun po 'di codice da più punti:

goto LABEL if $x;
...
goto LABEL if $y;
...
LABEL: ;

{
  last if $x;
  ...
  last if $y
  ...
}

Se è così, perché?

C non ha interruzioni multi-livello / etichettate e non tutti i flussi di controllo possono essere facilmente modellati con l'iterazione di C e le primitive decisionali. le goto fanno molto per rimediare a questi difetti.

A volte è più chiaro usare una variabile flag di qualche tipo per effettuare una sorta di interruzione pseudo-multi-livello, ma non è sempre superiore al goto (almeno un goto consente di determinare facilmente dove va il controllo, a differenza di una variabile flag ) e a volte semplicemente non si desidera pagare il prezzo di esecuzione di bandiere / altre contorsioni per evitare il goto.

libavcodec è un pezzo di codice sensibile alle prestazioni. L'espressione diretta del flusso di controllo è probabilmente una priorità, perché tenderà a funzionare meglio.

Allo stesso modo nessuno ha mai implementato la frase "COME FROM" ...

Trovo che do {} mentre (falso) utilizzo sia assolutamente ribelle. È concepibile potrebbe convincermi che è necessario in qualche caso strano, ma mai che sia un codice pulito e sensibile.

Se è necessario eseguire alcuni di questi cicli, perché non rendere esplicita la dipendenza dalla variabile flag?

for (stepfailed=0 ; ! stepfailed ; /*empty*/)

1) L'uso più comune di goto che conosco è emulare la gestione delle eccezioni in linguaggi che non lo offrono, in particolare in C. (Il codice fornito da Nuclear sopra è proprio questo.) Guarda il codice sorgente di Linux e tu ' Vedrò un bazillion goto usato in quel modo; c'erano circa 100.000 goto nel codice Linux secondo un rapido sondaggio condotto nel 2013: http://blog.regehr.org/archives/894 . L'utilizzo di Goto è anche menzionato nella guida allo stile di codifica Linux: https://www.kernel.org/doc/Documentation/CodingStyle . Proprio come la programmazione orientata agli oggetti viene emulata usando strutture popolate con puntatori a funzioni, goto ha il suo posto nella programmazione C. Quindi chi ha ragione: Dijkstra o Linus (e tutti i codificatori del kernel Linux)? Fondamentalmente è teoria contro pratica.

Esiste tuttavia il solito gotcha per non avere supporto a livello di compilatore e controlli per costrutti / schemi comuni: è più facile usarli in modo errato e introdurre bug senza controlli in fase di compilazione. Windows e Visual C ++ ma in modalità C offrono la gestione delle eccezioni tramite SEH / VEH proprio per questo: le eccezioni sono utili anche al di fuori dei linguaggi OOP, ovvero in un linguaggio procedurale. Ma il compilatore non può sempre salvare la tua pancetta, anche se offre supporto sintattico per le eccezioni nella lingua. Considera come esempio di quest'ultimo caso il famoso bug "goto fail" di Apple SSL, che ha appena duplicato un goto con conseguenze disastrose ( https://www.imperialviolet.org/2014/02/22/applebug.html ):

if (something())
  goto fail;
  goto fail; // copypasta bug
printf("Never reached\n");
fail:
  // control jumps here

Puoi avere esattamente lo stesso bug usando le eccezioni supportate dal compilatore, ad esempio in C ++:

struct Fail {};

try {
  if (something())
    throw Fail();
    throw Fail(); // copypasta bug
  printf("Never reached\n");
}
catch (Fail&) {
  // control jumps here
}

Ma entrambe le varianti del bug possono essere evitate se il compilatore analizza e ti avverte di un codice non raggiungibile. Ad esempio la compilazione con Visual C ++ a livello di avviso / W4 trova il bug in entrambi i casi. Java, per esempio, proibisce il codice irraggiungibile (dove può trovarlo!) Per una ragione abbastanza buona: è probabile che sia un bug nel codice medio di Joe. Fintanto che il costrutto goto non consente obiettivi che il compilatore non può facilmente capire, come goto per indirizzi calcolati (**), non è più difficile per il compilatore trovare un codice irraggiungibile all'interno di una funzione con goto che usare Dijkstra codice approvato.

(**) Nota a piè di pagina: sono possibili goto a numeri di riga calcolati in alcune versioni di Basic, ad es. GOTO 10 * x dove x è una variabile. Piuttosto confusamente, in Fortran "goto calcolato" si riferisce a un costrutto equivalente a un'istruzione switch in C. Lo standard C non consente goto calcolati nella lingua, ma solo goto a etichette dichiarate staticamente / sintatticamente. GNU C ha tuttavia un'estensione per ottenere l'indirizzo di un'etichetta (operatore unario, prefisso &&) e consente anche di passare a una variabile di tipo void *. Vedi https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html per ulteriori informazioni su questo oscuro argomento secondario. Il resto di questo post non si preoccupa di quella oscura funzionalità di GNU C.

Le gotos standard C (cioè non calcolate) non sono in genere il motivo per cui non è possibile trovare il codice non raggiungibile al momento della compilazione. Il solito motivo è il codice logico come il seguente. Dato

int computation1() {
  return 1;
}

int computation2() {
  return computation1();
}

È altrettanto difficile per un compilatore trovare il codice non raggiungibile in uno dei seguenti 3 costrutti:

void tough1() {
  if (computation1() != computation2())
    printf("Unreachable\n");
}

void tough2() {
  if (computation1() == computation2())
    goto out;
  printf("Unreachable\n");
out:;
}

struct Out{};

void tough3() {
  try {
    if (computation1() == computation2())
      throw Out();
    printf("Unreachable\n");
  }
  catch (Out&) {
  }
}

(Scusa il mio stile di codifica correlato alla parentesi graffa, ma ho cercato di mantenere gli esempi il più compatti possibile.)

Visual C ++ / W4 (anche con / Ox) non riesce a trovare il codice irraggiungibile in nessuno di questi e, come probabilmente saprai, il problema di trovare un codice irraggiungibile in generale è indecidibile. (Se non ci credi: https://www.cl.cam.ac.uk/teaching/2006/OptComp/slides/lecture02.pdf )

Come problema correlato, C goto può essere usato per emulare eccezioni solo all'interno del corpo di una funzione. La libreria C standard offre una coppia di funzioni setjmp () e longjmp () per emulare uscite / eccezioni non locali, ma queste presentano alcuni seri inconvenienti rispetto a ciò che offrono altre lingue. L'articolo di Wikipedia http://en.wikipedia.org/wiki/Setjmp.h spiega abbastanza bene quest'ultima questione. Questa coppia di funzioni funziona anche su Windows ( http://msdn.microsoft.com/en-us/library/yz2ez4as.aspx ), ma quasi nessuno li usa perché SEH / VEH è superiore. Anche su Unix, penso che setjmp e longjmp siano usati molto raramente.

2) Penso che il secondo uso più comune di goto in C sia l'implementazione di interruzioni multilivello o continui multilivello, che è anche un caso d'uso abbastanza controverso. Ricorda che Java non consente di andare all'etichetta, ma consente di interrompere l'etichetta o continuare l'etichetta. Secondo http://www.oracle.com/technetwork/java/simple-142616.html , questo è in realtà il caso d'uso più comune di goto in C (90% dicono), ma nella mia esperienza soggettiva, il codice di sistema tende utilizzare gotos per la gestione degli errori più spesso. Forse nel codice scientifico o in cui il sistema operativo offre la gestione delle eccezioni (Windows), le uscite multilivello sono il caso d'uso dominante. In realtà non forniscono alcun dettaglio sul contesto del loro sondaggio.

Modificato per aggiungere: risulta che questi due schemi di utilizzo si trovano nel libro C di Kernighan e Ritchie, intorno a pagina 60 (a seconda dell'edizione). Un'altra cosa da notare è che entrambi i casi d'uso riguardano solo goto in avanti. E si scopre che l'edizione MISRA C 2012 (a differenza dell'edizione 2004) ora consente goto, purché siano solo avanti.

Alcuni dicono che non c'è motivo per andare in C ++. Alcuni affermano che nel 99% dei casi ci sono alternative migliori. Questo non è un ragionamento, solo impressioni irrazionali. Ecco un solido esempio in cui goto porta a un bel codice, qualcosa come un ciclo do-while migliorato:

int i;

PROMPT_INSERT_NUMBER:
  std::cout << "insert number: ";
  std::cin >> i;
  if(std::cin.fail()) {
    std::cin.clear();
    std::cin.ignore(1000,'\n');
    goto PROMPT_INSERT_NUMBER;          
  }

std::cout << "your number is " << i;

Confrontalo con il codice goto-free:

int i;

bool loop;
do {
  loop = false;
  std::cout << "insert number: ";
  std::cin >> i;
  if(std::cin.fail()) {
    std::cin.clear();
    std::cin.ignore(1000,'\n');
    loop = true;          
  }
} while(loop);

std::cout << "your number is " << i;

Vedo queste differenze:

• {}è necessario il blocco nidificato (anche se do {...} whilesembra più familiare)
• loopè necessaria una variabile extra , utilizzata in quattro punti
• ci vuole più tempo per leggere e capire il lavoro con loop
• il loopnon possiede dati, li controlla il flusso di esecuzione, che è meno comprensibile che semplice etichetta

C'è un altro esempio

void sort(int* array, int length) {
SORT:
  for(int i=0; i<length-1; ++i) if(array[i]>array[i+1]) {
    swap(data[i], data[i+1]);
    goto SORT; // it is very easy to understand this code, right?
  }
}

Ora liberiamoci del "male" goto:

void sort(int* array, int length) {
  bool seemslegit;
  do {
    seemslegit = true;
    for(int i=0; i<length-1; ++i) if(array[i]>array[i+1]) {
      swap(data[i], data[i+1]);
      seemslegit = false;
    }
  } while(!seemslegit);
}

Vedi che è lo stesso tipo di utilizzo di goto, è un modello ben strutturato e non è goto in avanti come molti promuovono come l'unico modo consigliato. Sicuramente vuoi evitare un codice "intelligente" come questo:

void sort(int* array, int length) {
  for(int i=0; i<length-1; ++i) if(array[i]>array[i+1]) {
    swap(data[i], data[i+1]);
    i = -1; // it works, but WTF on the first glance
  }
}

Il punto è che goto può essere facilmente abusato, ma Goto stesso non è da biasimare. Si noti che l'etichetta ha l'ambito della funzione in C ++, quindi non inquina l'ambito globale come nell'assemblaggio puro, in cui i circuiti sovrapposti hanno il loro posto e sono molto comuni - come nel codice seguente per 8051, in cui il display a 7 segmenti è collegato a P1. Il programma avvolge il segmento dei fulmini attorno a:

; P1 states loops
; 11111110 <-
; 11111101  |
; 11111011  |
; 11110111  |
; 11101111  |
; 11011111  |
; |_________|

init_roll_state:
    MOV P1,#11111110b
    ACALL delay
next_roll_state:
    MOV A,P1
    RL A
    MOV P1,A
    ACALL delay
    JNB P1.5, init_roll_state
    SJMP next_roll_state

C'è un altro vantaggio: goto può servire come loop denominati, condizioni e altri flussi:

if(valid) {
  do { // while(loop)

// more than one page of code here
// so it is better to comment the meaning
// of the corresponding curly bracket

  } while(loop);
} // if(valid)

Oppure puoi usare goto equivalente con rientro, quindi non hai bisogno di commenti se scegli saggiamente il nome dell'etichetta:

if(!valid) goto NOTVALID;
  LOOPBACK:

// more than one page of code here

  if(loop) goto LOOPBACK;
NOTVALID:;

In Perl, usa un'etichetta per "andare" da un ciclo - usando un'istruzione "last", che è simile a break.

Ciò consente un migliore controllo sui loop nidificati.

Anche la tradizionale etichetta goto è supportata, ma non sono sicuro che ci siano troppi casi in cui questo è l'unico modo per ottenere ciò che vuoi: subroutine e loop dovrebbero essere sufficienti per la maggior parte dei casi.

Il problema con "goto" e l'argomento più importante del movimento di "programmazione goto-less" è che se lo usi troppo frequentemente il tuo codice, sebbene possa comportarsi correttamente, diventa illeggibile, non mantenibile, non visualizzabile ecc. Nel 99,99% di il caso 'goto' porta al codice spaghetti. Personalmente, non riesco a pensare a nessuna buona ragione per cui dovrei usare 'goto'.

Il GOTO può essere usato, ovviamente, ma c'è una cosa più importante dello stile del codice, o se il codice è o non è leggibile che devi tenere a mente quando lo usi: il codice all'interno potrebbe non essere robusto come te pensa .

Ad esempio, guarda i seguenti due frammenti di codice:

If A <> 0 Then A = 0 EndIf
Write("Value of A:" + A)

Un codice equivalente con GOTO

If A == 0 Then GOTO FINAL EndIf
   A = 0
FINAL:
Write("Value of A:" + A)

La prima cosa che pensiamo è che il risultato di entrambi i bit di codice sarà quel "Valore di A: 0" (supponiamo un'esecuzione senza parallelismo, ovviamente)

Non è corretto: nel primo esempio, A sarà sempre 0, ma nel secondo campione (con l'istruzione GOTO) A potrebbe non essere 0. Perché?

Il motivo è perché da un altro punto del programma posso inserire un GOTO FINALsenza controllare il valore di A.

Questo esempio è molto ovvio, ma man mano che i programmi diventano più complicati, aumenta la difficoltà di vedere questo tipo di cose.

Materiale correlato può essere trovato nel famoso articolo di Dijkstra "Un caso contro la dichiarazione GO TO"

Uso goto nel seguente caso: quando necessario per tornare da funzioni in luoghi diversi, e prima di tornare è necessario eseguire alcune inizializzazioni:

versione non goto:

int doSomething (struct my_complicated_stuff *ctx)    
{
    db_conn *conn;
    RSA *key;
    char *temp_data;
    conn = db_connect();  


    if (ctx->smth->needs_alloc) {
      temp_data=malloc(ctx->some_size);
      if (!temp_data) {
        db_disconnect(conn);
        return -1;      
        }
    }

    ...

    if (!ctx->smth->needs_to_be_processed) {
        free(temp_data);    
        db_disconnect(conn);    
        return -2;
    }

    pthread_mutex_lock(ctx->mutex);

    if (ctx->some_other_thing->error) {
        pthread_mutex_unlock(ctx->mutex);
        free(temp_data);
        db_disconnect(conn);        
        return -3;  
    }

    ...

    key=rsa_load_key(....);

    ...

    if (ctx->something_else->error) {
         rsa_free(key); 
         pthread_mutex_unlock(ctx->mutex);
         free(temp_data);
         db_disconnect(conn);       
         return -4;  
    }

    if (ctx->something_else->additional_check) {
         rsa_free(key); 
         pthread_mutex_unlock(ctx->mutex);
         free(temp_data);
         db_disconnect(conn);       
         return -5;  
    }


    pthread_mutex_unlock(ctx->mutex);
    free(temp_data);    
    db_disconnect(conn);    
    return 0;     
}

vai alla versione:

int doSomething_goto (struct my_complicated_stuff *ctx)
{
    int ret=0;
    db_conn *conn;
    RSA *key;
    char *temp_data;
    conn = db_connect();  


    if (ctx->smth->needs_alloc) {
      temp_data=malloc(ctx->some_size);
      if (!temp_data) {
            ret=-1;
           goto exit_db;   
          }
    }

    ...

    if (!ctx->smth->needs_to_be_processed) {
        ret=-2;
        goto exit_freetmp;      
    }

    pthread_mutex_lock(ctx->mutex);

    if (ctx->some_other_thing->error) {
        ret=-3;
        goto exit;  
    }

    ...

    key=rsa_load_key(....);

    ...

    if (ctx->something_else->error) {
        ret=-4;
        goto exit_freekey; 
    }

    if (ctx->something_else->additional_check) {
        ret=-5;
        goto exit_freekey;  
    }

exit_freekey:
    rsa_free(key);
exit:    
    pthread_mutex_unlock(ctx->mutex);
exit_freetmp:
    free(temp_data);        
exit_db:
    db_disconnect(conn);    
    return ret;     
}

La seconda versione semplifica, quando è necessario modificare qualcosa nelle istruzioni di deallocazione (ognuna viene utilizzata una volta nel codice) e riduce la possibilità di saltare una di esse quando si aggiunge un nuovo ramo. Spostarli in una funzione non aiuta qui, perché la deallocazione può essere fatta a diversi "livelli".

Edsger Dijkstra, un informatico che ha avuto importanti contributi sul campo, era anche famoso per aver criticato l'uso di GoTo. C'è un breve articolo sul suo argomento su Wikipedia .

Di tanto in tanto è utile per l'elaborazione delle stringhe in termini di caratteri.

Immagina qualcosa come questo esempio printf-esque:

for cur_char, next_char in sliding_window(input_string) {
    if cur_char == '%' {
        if next_char == '%' {
            cur_char_index += 1
            goto handle_literal
        }
        # Some additional logic
        if chars_should_be_handled_literally() {
            goto handle_literal
        }
        # Handle the format
    }
    # some other control characters
    else {
      handle_literal:
        # Complicated logic here
        # Maybe it's writing to an array for some OpenGL calls later or something,
        # all while modifying a bunch of local variables declared outside the loop
    }
}

Potresti ricondurlo goto handle_literala una chiamata di funzione, ma se sta modificando diverse variabili locali diverse, dovresti passare i riferimenti a ciascuna a meno che la tua lingua non supporti chiusure mutabili. Dovresti ancora usare acontinue un'istruzione (che è probabilmente una forma di goto) dopo la chiamata per ottenere la stessa semantica se la tua logica non fa funzionare un altro caso.

Ho anche usato le foto in modo giudizioso nei lexer, in genere per casi simili. Non hai bisogno di loro per la maggior parte del tempo, ma sono carini da avere per quegli strani casi.