GOTO encore considéré comme dangereux?

Question

Tout le monde est conscient de Dijkstra de Lettres à l'éditeur: aller à l'énoncé considéré comme nocif (également ici .html transcription et ici .pdf) et il y a eu une formidable poussée depuis ce temps à fuir l'instruction goto chaque fois que possible. Alors qu'il est possible d'utiliser la fonction goto pour produire désuète, tentaculaire code, il reste néanmoins dans les langages de programmation modernes. Même les avancées de la continuation de la structure de contrôle dans le Régime peut être décrite comme un système sophistiqué de goto.

Ce que les circonstances le justifient l'utilisation de goto? Quand est-il mieux éviter?

Comme une réponse à la question: C fournit une paire de fonctions setjmp et longjmp, qui offrent la possibilité de goto non seulement au sein de l'actuel cadre de la pile, mais dans toute l'appel des cadres. Devraient-ils être considérés comme dangereux que goto? Plus dangereux?

---

Dijkstra lui-même a regretté que le titre, pour lequel il n'était pas responsable. À la fin de EWD1308 (également ici .pdf), il écrit:

Enfin, une courte histoire de l'enregistrement. En 1968, les Communications de l'ACM publié un texte de la mine en vertu de la le titre "L'instruction goto considéré comme nuisibles", qui dans les dernières années les plus fréquemment citées, malheureusement, cependant, souvent par les auteurs qui avait vu plus que sa le titre, qui est devenu une pierre angulaire de la ma renommée en devenant un modèle: nous serait-voir toutes sortes d'articles sous le titre "X considérées comme nuisibles" pour presque tout X, dont l'un intitulé "Dijkstra considéré comme nocif". Mais ce qui s'était passé? J'avais présenté un papier sous le titre "Une affaire à l'encontre de l'instruction goto", qui, dans l'ordre pour accélérer sa publication, la l'éditeur avait changé dans une "lettre à l'Éditeur", et dans le processus, il a lui a donné un nouveau titre de son propre l'invention! L'éditeur a été Niklaus Wirth.

Bien pensée classique papier sur ce sujet, pour être jumelé à celui de Dijkstra, est la Programmation Structurée avec aller à des Déclarations, par Donald E. Knuth. La lecture contribue à rétablir le contexte et non dogmatique de la compréhension de l'objet. Dans ce papier, Dijkstra est d'avis sur ce cas est signalé et est encore plus forte:

Donald E. Knuth: je crois que, par la présentation d'une telle vue que je ne suis pas en fait en désaccord fortement avec Dijkstra idées, depuis récemment, il a écrit ce qui suit: "S'il vous plaît, ne tombez pas dans le piège de croire que je suis terriblement dogmatical sur [aller à déclaration]. J'ai du mal à l'aise sentiment que les autres font religion, comme si le les problèmes conceptuels de la programmation pourrait être résolu par un seul truc, par un simple formulaire de codage de la discipline!"

Answer 1

http://xkcd.com/292/

---

Un collègue m'a dit que la seule raison d'utiliser un GOTO est si vous programmez vous-même jusqu'à présent dans un coin que c'est le seul moyen de sortir. En d'autres mots, le bon design à l'avance et vous n'aurez pas besoin d'utiliser un GOTO plus tard.

Je pensais que cette bande dessinée illustre magnifiquement "j'ai pu restructurer le programme de flux, ou d'en utiliser un peu de "GOTO" à la place." Un GOTO est un faible moyen de sortir quand vous avez une mauvaise conception. Velociraptors proie sur le faible.

Answer 2

Les énoncés suivants sont des généralisations; alors qu'il est toujours possible d'invoquer une exception, il est habituellement (dans mon expérience et mon humble avis) ne vaut pas les risques.

1. Sans contrainte d'utiliser des adresses de mémoire (soit GOTO ou raw pointeurs) offre aussi de nombreuses possibilités de faire des erreurs facilement évitables.
2. Le plus de manières, il y a pour arriver à un "emplacement" dans le code, les moins confiants, on peut être sur ce que l'état du système est à ce point. (Voir ci-dessous).
3. La programmation structurée à mon humble avis est moins sur "comment éviter les GOTOs" et plus sur la structure du code de correspondre à la structure des données. Par exemple, la répétition d'une structure de données (par exemple, tableau, fichier séquentiel, etc.) est naturellement traitées par une répétition de l'unité de code. Après avoir construit des structures (par exemple, tandis que, pour d', jusqu'à ce que, pour chacun, etc.) permet au programmeur pour éviter l'ennui de la répétition du même stéréotypés modèles de code.
4. Même si le GOTO est de faible niveau de détail de l'implémentation (pas toujours le cas!) il est au-dessous du niveau que le programmeur doit être pensée. Combien de programmeurs équilibrer leur vie personnelle chéquiers en binaire brut? Combien de programmeurs se soucier du secteur sur le disque contient un enregistrement particulier, au lieu de simplement fournir une clé pour un moteur de base de données (et de combien de façons est-ce qui pourrait aller mal si on a vraiment écrit de tous nos programmes en termes de secteurs physiques du disque dur?

Notes de bas de page ci-dessus:

Re point 2, considérons le code suivant:

a = b + 1
/* do something with a */

À la "faire quelque chose" dans le code, nous pouvons affirmer avec une confiance élevée que a est supérieur à b. (Oui, je suis en ignorant la possibilité de non interceptée débordement d'entier. Laissez pas embourber un exemple simple.)

D'autre part, si le code avait lu de cette façon:

...
goto 10
...
a = b + 1
10: /* do something with a */
...
goto 10
...

La multiplicité des façons d'obtenir de l'étiquette 10 signifie que nous devons travailler beaucoup plus difficile d'être confiant sur les relations entre a et b à ce point. (En fait, dans le cas général, c'est undecideable!)

Re point 4, soit de l'ensemble de la notion de "aller quelque part" dans le code est juste une métaphore. Rien n'est vraiment "aller" n'importe où à l'intérieur de la CPU à l'exception des électrons et des photons (de la chaleur résiduelle). Parfois nous donner une métaphore pour une autre, plus utiles. Je me souviens de la rencontre (il y a quelques décennies!) une langue où

if (some condition) {
  action-1
} else {
  action-2
}

a été mis en œuvre sur une machine virtuelle grâce à la compilation de l'action 1 et l'action-2 à l'extérieur de la ligne sans paramètre routines, puis à l'aide d'un seul à deux arguments VM opcode qui a utilisé la valeur booléenne de la condition d'invoquer l'une ou l'autre. Le concept a été tout simplement "choisir ce que pour appeler maintenant" plutôt que de "rendez-vous ici ou là". De nouveau, juste un changement de métaphore.

Answer 3

Parfois, il est valable d'utiliser GOTO comme une alternative à la gestion des exceptions au sein d'une seule fonction:

 if (f() == false) goto err_cleanup;
if (g() == false) goto err_cleanup;
if (h() == false) goto err_cleanup;

return;

err_cleanup:
...
 

Le code COM semble tomber assez souvent dans ce schéma.

Answer 4

Je ne peux me rappeler d'utiliser un goto qu'une seule fois. J'avais une série de cinq boucles comptées imbriquées et je devais être en mesure de sortir de toute la structure de l'intérieur de façon précoce en fonction de certaines conditions:

 for{
  for{
    for{
      for{
        for{
          if(stuff){
            GOTO ENDOFLOOPS;
          }
        }
      }
    }
  }
}

ENDOFLOOPS:
 

J'aurais pu facilement déclarer une variable de saut booléenne et l'utiliser comme partie du conditionnel pour chaque boucle, mais dans ce cas j'ai décidé qu'un GOTO était aussi pratique et aussi lisible.

Aucun vélociraptors ne m'a attaqué.

Answer 5

Nous avons déjà eu cette discussion et je maintiens mon point de vue.

En outre, j'en ai marre des gens décrire plus élevé au niveau des structures de la langue comme "goto dans le déguisement" parce qu'ils n'ont manifestement pas eu le point à tous. Par exemple:

Même les avancées de la continuation de la structure de contrôle dans le Régime peut être décrite comme un système sophistiqué de goto.

C'est un non-sens complet. Chaque structure de contrôle peuvent être mises en œuvre en termes de goto , mais cette observation est tout à fait insignifiant et inutile. goto n'est pas considéré comme nuisible en raison de ses effets positifs, mais en raison de ses conséquences négatives, et ils ont été éliminés par la programmation structurée.

De même, en disant: "GOTO est un outil, et comme tous les outils, il peut être utilisé et abusé" est complètement à côté de la marque. Aucune construction moderne travailleur serait d'utiliser un rocher et à prétendre qu'il "est un outil." Les roches ont été remplacés par des marteaux. goto a été remplacé par des structures de contrôle. Si le travailleur de la construction ont été bloqués dans la nature sans un marteau, bien sûr, il aurait recours à un rocher au lieu. Si un programmeur doit utiliser un niveau inférieur langage de programmation qui n'a pas de fonction de X, ainsi, bien sûr, elle peut avoir à utiliser goto à la place. Mais si elle l'utilise n'importe où d'autre à la place de la langue appropriée en fonction, elle a clairement n'a pas compris la langue correctement et l'utilise à tort. C'est vraiment aussi simple que cela.