goto
Ce post fait suite a la discussion amorcee dans le fil C++ et grand nombre (ferme car hors sujet).
Je pense que si les concepteurs du langage C/C++ ont conserve le mot-clef goto, c'est qu'il est utile dans certaines situations. Par exemple dans une situation ou il y a plusieurs tests a faire sur des variables de type non entiers, on ne peut pas utiliser une structure switch/case/break et il faut alors utiliser des if/else imbriques ce qui rend le code peu lisible. Une solution pour rendre le code lisible sans goto consiste a utiliser une fonction pour cette partie de code avec des return ce qui evite d'introduire des blocs else imbriques, mais c'est parfois complique et couteux a mettre en oeuvre (par exemple s'il y a plusieurs variables impliquees dans les tests ou si on modifie plusieurs variables dans les blocs), dans ces conditions un goto est plus lisible et efficace.
Adopter une position ideologique anti-goto simplement parce que le code etait difficile a suivre avant la generalisation des langages permettant la programmation structuree est a mon avis une absurdite. Il ne faut pas non plus oublier qu'en assembleur, on ne dispose pas de structure de boucle mais de branchements inconditionnels et conditionnels, s'interdire de les utiliser en programmation structuree (surtout dans un langage comme le C) c'est aussi ridicule que de s'interdire d'utiliser des boucles dans un langage a priori fonctionnel et recursif (ce qui etait le cas dans certaines implementations de logo si je ne m'abuse).
Sinon, pour repondre a Fin de partie, c'est justement parce que je travaille sur des projets faisant des centaines de milliers de lignes de code (dont 200 000 lignes de code dont je suis l'auteur pour giac/xcas), que je donne cet avis.
Je pense que si les concepteurs du langage C/C++ ont conserve le mot-clef goto, c'est qu'il est utile dans certaines situations. Par exemple dans une situation ou il y a plusieurs tests a faire sur des variables de type non entiers, on ne peut pas utiliser une structure switch/case/break et il faut alors utiliser des if/else imbriques ce qui rend le code peu lisible. Une solution pour rendre le code lisible sans goto consiste a utiliser une fonction pour cette partie de code avec des return ce qui evite d'introduire des blocs else imbriques, mais c'est parfois complique et couteux a mettre en oeuvre (par exemple s'il y a plusieurs variables impliquees dans les tests ou si on modifie plusieurs variables dans les blocs), dans ces conditions un goto est plus lisible et efficace.
Adopter une position ideologique anti-goto simplement parce que le code etait difficile a suivre avant la generalisation des langages permettant la programmation structuree est a mon avis une absurdite. Il ne faut pas non plus oublier qu'en assembleur, on ne dispose pas de structure de boucle mais de branchements inconditionnels et conditionnels, s'interdire de les utiliser en programmation structuree (surtout dans un langage comme le C) c'est aussi ridicule que de s'interdire d'utiliser des boucles dans un langage a priori fonctionnel et recursif (ce qui etait le cas dans certaines implementations de logo si je ne m'abuse).
Sinon, pour repondre a Fin de partie, c'est justement parce que je travaille sur des projets faisant des centaines de milliers de lignes de code (dont 200 000 lignes de code dont je suis l'auteur pour giac/xcas), que je donne cet avis.
Cette discussion a été fermée.
Réponses
Théorème:
Tout programme écrit dans un langage raisonnable et utilisant des goto peut être ré-écrit sans goto.
Ceci dit, Il m'est arrivé de programmer dans des langages exotiques en utilisant des goto, parce que je n'avais pas le choix, par exemple le macro-langage de GMP2D (années 80), mais en faisant un effort maximum de structuration.
Par contre, en C, C++, C#, il n'y a pas de raison.
Et j'ai aussi écrit des programmes avec beaucoup de lignes.
Cordialement,
Rescassol
-- Schnoebelen, Philippe
et Linus Torvalds
http://web.archive.org/web/20051128093253/http://kerneltrap.org/node/553/2131
Exemple (tiré de ce tutorial http://www.cplusplus.com/files/tutorial.pdf ) :
A l'instar de nombreux langages, il y a en C++ une simplification de syntaxe dans le cas du else if.
Pour le démontrer, on peut simplement transformer le programme avec Gotos comme suit :
On a même montré plus fort : une seule boucle while suffit.
Après, effectivement, c'est très moche comme programme.
Les anti-goto devraient se fendre d'un argument montrant qu'au prix max d'une ou deux lignes on peut le contourner, pas juste d'une réponse théorique. Encore une fois, on trouve ici des manifestations de la religion protypage, en gros une idéologie qui voudrait presque "interdire" aux programmeurs de ne pas bien typer leurs programmes. Et ça se traduit dans les faits.
-- Schnoebelen, Philippe
procedure debile (a: entier; var s:entier)
var b : entier;
begin
1) b:= random entier entre 2 et 6;
2) incrementer s
3) a:=a+s
4) debile(s,a); debile(a+b,s)
5) goto b
6) if a est pair then begin s:=10s; goto (random entier 1 et 4) end;
end;
Le principe général d'un programme informatique est la suite des instructions.
Si on cherche à écrire un ensemble de fonctions de calcul élémentaires, les lignes de code seront du type linéaire. Dans la pratique, l'informatique offre des possibilités beaucoup plus grandes.
Un simple boucle (for, while, do) contient obigatoirement une instruction du type jump. Les auteurs de langages ont masqué cela pour les boucles.
Pour les sorties de boucles, il y a la commande break, qui veut simplement dire "goto la ligne suivante de la fin de boucle".
Par curiosité, j'ai regardé dans mon programme si j'utilisais beaucoup de goto. Y'en a pas mal, mais ce sont des trucs du genre goto FIN, goto SUITE, goto Err etc.
Le langage C permet ce type de saut, le "théorème" cité par Rescassol est indéfendable, de même que l'argument "facilité".
Si on code avec ce type d'idées préconçues, on ne codera pas bien longtemps.
@Professeur Rectangle, je suis Rescassol et non Rescarol.
@CC tu n'as pas à sortir ton artillerie loggorhéo-idéologique.
Il se trouve que j'ai rencontré beaucoup d'étudiants écrivant des programmes en Basic ou Fortran, et qui, au fur et à mesure d'évolutions et de debugging, transformaient ça en sacs de noeuds illisibles à force d'abus de gotos.
Ça ne veut pas dire qu'on ne peut pas écrire un goto proprement, mais je maintiens qu'on peut s'en passer de façon tout aussi propre.
Si je n'aime pas les gotos, c'est simplement parce que les autoriser ne va pas dans le sens d'une bonne pédagogie de programmation.
Cordialement,
Rescassol
On évite GOTO
à Böhm-Jacopini.
Et tu as raison et de plus, tu ne risques pas d'être contredit par des théorèmes à la Rescassol ou PR, car sans break (ou instruction de contrôle de nature similaire), l'informatique ne réalise que la logique intuitionniste (autrement dit, essentiellement, pour être complèt un compilateur doit obligatoirement implémenter un break, et c'est un théorème fondamental, pas un théorème de maths appli (essentiellement dû à Timothy Griffin).
Je prends l'exemple académique du caml (c'est un "langage idéal" théoriquement). Il type automatiquement tous les programmes (quitte à créer des types paradoxaux) et est complet (tout ce qui est programmable, l'est en caml). Par ailleurs, si on ôte la commodité "rec" de "let rec", on obtient "ce qui est réalisable" (cela donne un bon critère pour juger de la valeur d'un langage). Et bien si EN PLUS on ôte "raise" (c'est l'instruction "break" de caml) , je mets au défi quiconque de réussir (sans rec, ni "raise", ni artifice utilisant des listes vides, etc) à obtenir:
blabla ;;
val callcc : (('a -> 'b) -> 'a) -> 'a = <fun>
Je suis étonné par ce témoignage. J'ai écrit mon dernier goto en 1988, quand j'ai abandonné mon MO5 et son Basic pour un PC et Turbo Pascal.
A l'époque, les ordinateurs personnels étaient livrés avec Basic en Rom. Mais aujourd'hui, qui rencontre encore Basic ?
Aléa, mon expérience étudiante en informatique remonte à 1980 et les étudiants privilégiés possédaient un Apple II avec Basic AppleSoft, j'ai ensuite rencontré Fortran à l'IUT de Cachan en 1982.
Cordialement,
Rescassol
Vers cette époque, quand j'étais au lycée on allait quelque fois s'initier à l'IUT de Cachan.... au Basic sur des ordinateurs Sun microsystème si je me souviens bien.
Si tu tolères les GOTO dans du code, pour coder plus vite, c'est à dire sans réfléchir, cela va devenir vite illisible et non maintenable. Quand tu codes en assembleur le point de vue est différent. B-)-
Pourrait-on avoir une petite exégèse de ton article (ton lien)? Il est assez long, en anglais et a l'air intéressant. Mais je n'ai pas la dispo.
Peux-tu expliquer la différence qu'il y a en C entre un break, un continue, un return, un switch et un goto ?
Tout ça, c'est exactement la même logique, la seule différence est qu'il ne sont pas interchangeables, d'où la nécessité de chacun, y compris le goto.
En1982, à l'IUT de Cachan, et j'y suis resté jusqu'en 1988, j'étais en DEA d'informatique à Paris 6 (et prof de lycée à Drancy), et j'y étais vacataire dans la formation continue de CAO dirigée par Michel Carrard.
J'y ai fait du Fortran, du C, du Pascal et des méthodes de lissage, plus de l'encadrement de projet.
Au début, on avait un PDP 11/34 avec 64 Ko de Ram en mutipostes sur une douzaine de postes.
Cordialement,
Rescassol
Quelqu'un qui maîtrise la programmation peut très bien se passer de ce commandement simpliste. Utiliser des goto qui vous envoient à l'autre bout du code est sans doute toujours une mauvaise idée. Utilisez un goto (ou un avatar) pour aller dix lignes plus loin ou plus haut dans un petit bout de code n'est a priori pas criticable.
99% des logiciels ne servent pas à ça:
1) Ils bouclent par vocation (un OS qui ne bouclerait pas serait un scandale)
2) Ils traitent des données non déterministes
3) Ils peuvent devoir être appelés à être compatibles avec la programmation parallèle asynchrone.
Le typage ressemble à la logique (écrite avec le signe "implique"). On peut prouver que la programmation structurée (sans goto ni avatar) réalise essentiellement la logique intuitionniste (et ses prolongements). Cela démontre aussi que "goto" (ou autre avatar de même nature) sont nécessaires. En effet, la logique classique est (et se doit être) réalisable. Qu'est-ce que c'est la logique classique (ici)? C'est la possibilité, quand on vous donne une garantie de (A=>B)=>A de malaxer le produit si j'ose dire pour le magnifier en une garantie de A.
Tant que les A,B,C sont des phrases et que la flèche veut dire "implique", ça ne pose pas de problème: les matheux, même non logiciens (exemple SN récemment) sortent leur révolver (ie leur table de vérité) et disent "bon, bon, bon: si A est faux, alors, A=>B, donc A. Si A est vrai alors A"
Mais ça ne marche pas comme ça en informatique: les lettres majuscules ci-dessus ne fonctionnent pas forcément comme des phrases "classiques". La plupart des garanties de la vie courantes sont difficilement assimilables à des phrases classiques. il n'y a pas de "vrai" et de "faux" chers aux platoniciens. On dispose bien de =>, et de non (précision: non(A) est le type des noms qu'on donne aux objets vivant dans A, ie aux pointeurs vers A), mais pas de "étant donné 3 phrases, deux d'entre elles sont équivalentes".
Donc question: comment réaliser l'objectif A quand on nous donne en entrée un objet de type f: (A=>B)=>A. Je reraconte pour la 236878ième fois, comment l'informaticien fait: il propose à f un agent inflitré que j'appelle u qui a l'effet suivant. Si lors de l'exécution de f(u), la procédure implémentant f demande à u(truc) de s'exécuter (où truc est de type A), et bin, u va trahir: il va tout stopper, mettre truc dans sa poche, et l'emmener à l'appelant émetteur. Par contre, si f ne se sert pas de u, on laisse couler.
Ca donne la programmation suivante:
function a: A begin réserver l'adresse 123; exécute f(u) // si exception se produit récupère la donnée à l'adresse 123 end
au préalable: on a programmé u comme suit: function u(x:A): B begin enregistre x à l'adresse 123; déclencher exception Stop; end
(Pour ceux qui aiment le caml:
exception Stop
let bluf r x = begin r:=x:: (!r); raise(Stop) end
let callcc u = let r=ref [] in try u (bluf r)
with | Stop ->
match (!r) with
| []->raise Stop
| x::li->x;;
donnant comme réponse du compilateur:
exception Stop
val bluf : 'a list ref -> 'a -> 'b = <fun>
val callcc : (('a -> 'b) -> 'a) -> 'a = <fun>
)
Exercice: montrer que sans procédure "exit" ou goto ou n'importe quel avatar, il existe des programmes faisant des choses avec (dans le paradigme élargi) qui ne sont simulables par aucun programme qui n'en disposent pas.
Un essai sans goto :
Soit A la procédure
test1:=vrai; tant que test1 {ligne 20 ligne 30 test1:=(...) }Soit B la procédure
test2:=vrai; tant que test 2 {ligne 30 A ligne 50 test2:=(...) }Finalement, le programme devient
-- Schnoebelen, Philippe
Je ne comprends pas ce que vient faire ici le goto.
Un break permet de sortir d'une boucle, un continue permet, sauf erreur, de zapper tout ce qui suit dans la boucle et de reprendre la boucle au départ mais dans la continuité. Un return permet de sortir d'une fonction, ou du programme s'il est exécuté hors du code d'une fonction/sous-programme, un switch est une généralisation au if else qui permet de structurer le code.
Le goto marque une rupture inconditionnelle dans l'exécution du code , on peut mettre le label où on veut, dans une boucle pour em... celui ou celle qui va avoir à faire la maintenance du code. B-)
Le continue provoque la suite du programme à dernière ligne du bloc.
Le return provoque la suite du programme à la dernière ligne de la fonction.
Le switch est une liste de goto numérotés.
Le goto provoque la suite du programme à une adresse spécifiée.
Un compilateur normal n'accepte pas l'adresse de destination d'un goto à l'intérieur d'aun bloc.
En fait, on ne peut utiliser un goto qu'avec un rigeur particulière.
Par exemple ce code
for (...)
{
ADRESSE :
{
...
}
}
goto ADRESSE;
ne passera pas.
Le goto est une instruction comme une autre qui doit être utilisée lorsque c'est plus pratique et plus clair.
Si tu arrives à compiler un code avec un label de goto n'importe où, merci de bien vouloir le copier et indiquer le nom du compilateur.
Tu peux même faire un saut au milieu d'une instruction (vieille astuce pour planter les débugueurs).
Typiquement, le type que vous proposez n'est pas possible en C à cause du polymorphisme. Diriez-vous que C n'est pas complet ?
Bref, ne pas confondre complétude et typage.
Remarque : Pourquoi choisir un type si compliqué et pas tout simplement 'a->'b ? Sauf erreur de ma part, on a besoin de la récursivité ou des exceptions pour faire 'a->'b.
On fait fi du break (high IR).
Enfin une question!! Une fois de plus dans ton premier paragraphe, tu as adopté un style docte qui cache que tu voulais poser une question. Sache (je me répète et il n'y a pas d'animosité) que c'est ambigu pour les visiteurs google qui cherchent des infos. Après tout, on poste "aussi" pour eux, non?
Mon but était de convaincre de quelque chose. La caml implémente directement (ie sans demander à l'auteur des programmes) une inférence de typage: ce qui signifie que quand tu tapes un programme, à la fin, sans que tu ne fasse rien, il te renvoie "val" suivi de ce qui s'apparente à un "énoncé" (qui ressemble un peu à du langage mathématique écrit avec "=>") qui doit être lu comme "prouvé" par le programme que tu viens de taper (sinon, il t'envoie dans les choux en te disant qu'il ne peut pas typer ton programme). Tout ceci est inspiré de la correspondance de Curry Howard, et même, très précisément, implémente en "chair et en os" si j'ose dire le lambda-calcul. Bien évidemment, l'INRIA ne pouvait pas résoudre tous les problèmes (dont certains sont ouverts encore actuellement !!!) afférant à cette spécialité. Contrairement à COQ par exemple, et d'autres outils, je trouve qu'il ont fait le meilleur choix (celui de ne pas brider le programmeur X ou Y, pas forcément féru de logique informatique, et éventuellement appelé à programmer en caml des projets réellement industriels et important): prendre par la main le programmeur en douceur, en lui "imposant" les découvertes de la CorCuHO, tout en lui permettant de programmer ce qu'il veut (ie de ne pas ôter de puissance à ce que l'informatique permet théoriquement de faire). Dès lors, il était inévitable (puisque c'est un problème non résolu même en maths) d'accepter de considérer des fonctions plutôt que des applications.
Autrement dit, une fonction partielle (par exemple l'ensemble vide), allant de A dans B était acceptable et devait pouvoir recevoir le type $A\to B$.
Par contre, quand on évalue ce que réalise une machine, il faut être honnête. Je ne peux pas poster sur le forum, et utiliser un argument qui dit que le caml est puissant car il réalise le type $\forall X, Y: (X\to Y)$ en exhibant la fonction vide qui l'habite. La fonction vide habite tous les $A\to B$ quelque soit $A,B$. Je ne vais détailler ce qu'on appelle "être honnête" mais ça reçoit une définition formelle. Une fois acceptée cette définition, il y a un point important:
Il y a plusieurs définitions de ce que veut dire "être honnête" qui sont toutes plus ou moins équivalentes. Les concepteurs de caml ont pris le plus grand soin qu'il était possible de prendre pour éviter les raccourcis invalides. Par exemple, si tu tapes:
raise;;
- : exn -> 'a = <fun>
le mot "raise" est une instruction primitive du caml. Elle est "de toute pièce" une instruction qui semble garantir l'accès au paradis (puisque 'b peut être n'importe quoi à partir du moment où on lui fournit un objet de type "exception"
Autre exemple, si tu tapes:
# let r = ref [];;
val r : '_a list ref = {contents = []}
# let f x = match (!r) with
| y::li ->y;;
Characters 10-41:
..........match (!r) with
| y::li ->y..
Warning 8: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
[]
val f : 'a -> '_b = <fun>
Le compilateur accepte de reconnaitre que tu as "réussi" à trouver un élément de $A\to B$ pour $A,B$ quelconques, mais il signale quand-même un petit underscore et un warning pour dire que ta fonction est très partielle.
Pour enlever l'underscore, tu rends locale la liste vide:
let f x = let s = ref [] in match (!s) with y::li -> y;;
Characters 28-54:
let f x = let s = ref [] in match (!s) with y::li -> y;;
^^^^^^^^^^^^^^^^^^^^^^^^^^
Warning 8: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
[]
val f : 'a -> 'b = <fun>
Etc, etc. De toute façon, toutes ces programmations sont une manière de tricher (ie une triche explicitement autorisée par l'INRIA pour ne pas brider caml) en exhibant l'ensemble vide comme une fonction partielle habitant $X\to Y$. Attention: il n'y a absolument pas besoin du type exn pour le faire (tu posais la question). Par contre, il est inévitalbe que je reçoive des "warning" ou alors que je les court-circuite en exploitant exn.
Bref, une fois éliminé tous ces "à côtés", on parvient (et c'est usuel) à dresser la liste de ce qu'un langage permet "VRAIMENT" de réaliser (comme sous-ensemble de l'ensemble de tautologies), et quand il est réalise toutes les tautologies , il est théoriquement de puissance maximale (ie il suffit de lui rajouter rec pour avoir l'équivalent de l'assembleur en puissance). C'est pourquoi, j'ai expliqué comment réaliser (sans tricher) le seul axiome que la logique intuitionniste ne contient pas et qui, quand on le lui ajoute, entraîne toute la logique classique, à savoir $((A\to
Une "bonne" analyse des langages impératifs serait assez compliquée, d'autant qu'il faudrait donner une vraie importance à l'opération $\circ$ qui est le commuté du "point-virgule".
Edit: j'ai mis en bleu ce que j'ai tapé et en vert ce que le compilateur répond.
# exception Stop
let bluf r x = begin r:=x:: (!r); raise(Stop) end
let callcc u = let r=ref [] in try u (bluf r)
with | Stop ->
match (!r) with
| []->raise Stop
| x::li->x
;;
exception Stop
val bluf : 'a list ref -> 'a -> 'b = <fun>
val callcc : (('a -> 'b) -> 'a) -> 'a = <fun>
edit: oups, si, bon pas grave
Bon bin, j'améliore pour la précision de ma réponse à PR
Dans :
exception Stop
exception GrosBug
let bluf r x = begin r:=x:: (!r); raise(Stop) end
let callcc u = let r=ref [] in try u (bluf r)
with | Stop ->
match (!r) with
| []->raise GrosBug
| x::li->x;;
exception Stop
exception GrosBug
val bluf : 'a list ref -> 'a -> 'b = <fun>
val callcc : (('a -> 'b) -> 'a) -> 'a = <fun>
L'exploitation de ce procédé ne déclenchera JAMAIS l'exception GrosBug.
Les dix règles en puissance.
La sécurité confirme MISRA.
C'est une blague. Evidemment tous ces textes normatifs, écrits en anglais, sont écrits par des despotes qui ne voient que leur petit monde (la comptabilité du resto routier qui borde l'autoroute qu'ils prennent le matin pour aller dans leur boite)
Il faut reconnaître que dans le privé 99% des programmeurs ne font que ça (des logiciels triviaux accomplissant des tâches pratiques triviales), et se moquent éperdument de ce que permettrait "théoriquement" de faire un ordinateur. Il y a deux mondes professionnels en fait: les uns qui essaient d'améliorer des logiciels triviaux comme un "word" qui marche plus vite, etc et les autres qui "ont plus de temps à laisser à leur machine à l'exécution" mais ne cherchent pas "le produit qui va se vendre", mais plutôt le produit qui va réfléchir à leur place. Exemple: ce serait complètement stupide de programmer un gagneur automatique au jeu de dames ou au morpion sans utiliser la récursivité.
Navettes $\neq$ Théorie Jeux
En pseudo code, en réutilisant la preuve que j'ai mentionnée avant :
On peut aussi faire des fonctions mutuellement récursives :
FAUX.
Ce "théorème" ne vaut pas que dans ces conditions limités, confer la preuve que j'ai donné qui marche y compris avec des programmes faisant des trucs plus compliqués que prendre une entrée et rendre une sortie. Ça marche aussi avec les programmes ne terminant jamais, et la preuve s'adapte très facilement au cas parallèle.
Bref, cessez d'affirmer péremptoirement, sans jamais rien prouver, des choses fausses.
Le but de ces contraintes est d'avoir des programmes sûrs, sans bug. La NASA n'a pas envie que du code embarqué dans un de leurs engins bugs et entraine la perte de l'appareil.
Ils imposent donc des contraintes drastiques.
Des contraintes tout aussi drastiques sont imposées en France dans les avions et les satellites.
Il faut comprendre qu'écrire un programme pour un PC, ce n'est pas pareil : personne ne va mourir si le PC plante. Si on veut qu'un programme ne plante pas, on n'utilise pas de Goto, ou alors que dans des cas extrêmement règlementés. Même chose pour les while.
Concernant l'allocation dynamique de mémoire, c'est très dangereux : l'allocation peut échouer s'il n'y a plus de "place". Il vaut mieux gérer toute la mémoire de l'appareil (surtout que sur de l'embarqué, le contexte est connu et bien encadré).
Tu n'as vraiment pas suivi, c'est tout de même assez pénible car ce n'est pas la première fois. Tu as donné une preuve hors-sujet utilisant des avatars de goto, tu viens de le refaire et dans un cas extrêmement simple, non parce que tu ne comprends pas mais parce que tu ne suis pas: les intervenants (pas moi!!) qui t'ont succédé ont abordé le sujet des avatars de goto pas juste de goto et lui seul (relis le fil). Par ailleurs, puisque tu te sens capable de prouver "ton théorème" presque pour ainsi dire dans une forme n'exigeant aucun condition de validité, alors poste un programme caml qui réalise (('a->'b)->'a)->'a sans tricher (ie sans "rec", "raise", ou utiliser des fonctions partielles artificielles), puisque c'est de ça qu'il était question. Après tout si tu as une preuve, rien ne t'empêche de la poster.
Mais oui bien sûr, je vais perdre mon temps à poster une preuve du fait que (('a->'b)->'a)->'a n'est pas un théorème de la logique intuitionniste (je n'ai essentiellement rien affirmé de plus) alors que j'ai déjà dû le faire 15 mille fois sur le forum et que ça te prendra montre en main 10mn à retrouver si tu fais un petit effort. Un conseil : lis tout ou sinon sois modéré dans tes réactions. Et uis un petit merci de temps en temps quand on t'apprend des trucs ne serait pas forcément inutile si tu vois ce que je veux dire :-D (même si je respecte que chacun a sa façon de poser des question et que la posture sceptique-procureur a son intérêt)
D'accord avec toi sur ce point que quand la production devient collective, il faut prendre des précautions. Mais contrairement à ce que disait fdp, je me vois mal (et je ne crois pas que ce soit si fréquent) lire ligne à ligne un code d'un autre même bien écrit. J'ai l'impression que les codes c'est fait pour être compilé et exécuté. Quand la fonction programmée par Bidule cafouille, on la vire du code, point. D'où le développement SURTOUT (me semble-t-il) de techniques de bibliothèques. Mais je me trompe peut-être: peut-être y a-t-il des gens payés à parcourir les centaines de milliers de lignes pour débusquer la petite souris espiègle qui faisait capoter le truc.
En pas loin de 35 ans de programmation (Pascal, C, C++, C#, Python entre autres),je n'ai jamais utilisé les mots "goto, "continue", "break" (sauf dans un switch) tout simplement parce que j'ai appris comme ça et que j'ai toujours pu m'en passer facilement.
Par contre, il m'arrive d'écrire "if test return something" dans une fonction, et j'ai bien sûr utilisé la récursivité (quand ça se justifiait) qui ne me semble pas avoir quoi que ce soit avec goto et ses avatars.
while ne me paraît pas non plus un goto déguisé.
Et enfin j'ai interdit ces pratiques à mes étudiants pour des raisons pédagogiques.
Cordialement,
Rescassol
Tu parles d'une époque (années 1980) où le Basic était encore couramment utilisé, mais est-ce que de nos jours les étudiants abusent encore du goto si on ne leur interdit pas ?
A cette époque (en 1980), je programmais en Pascal UCSD sur Apple II.
Mais depuis que j'enseigne la programmation, vers 1984 ou 85 environ, j'ai toujours vu quelques (rares) étudiants me sortir un goto de temps en temps, et encore aujourd'hui.
Mais il est vrai qu'il n'y en a pas des quantités.
Cordialement,
Rescassol
Il me souvient du temps du BASIC (sur diverses plateformes), ou le goto était souvent utilisé dans un if ... then goto ... en lieu et place des boucles while ou repeat, soit parce qu'elles n'existaient pas, soit parce qu'on ne les connaissait pas (eh oui, je fais partie du grand nombre de gens qui ont appris à programmer sans livre), soit parce qu' étant obligé de numéroter les lignes dans certains basic, commencer une boucle à un certain endroit et terminer beaucoup plus loin n'était pas particulièrement agréable à lire. Et puis les éditeurs n'étaient pas aussi pratiques, et les tabulations pour rendre le code agréable à lire ou les commentaires du code tenaient trop de place et étaient peu usités.
Un banal if ... then goto ... faisait alors le même effet qu'un while ou un repeat (selon l'endroit où il était placé), et était peut-être plus explicite pour un débutant. Conjointement, je programmais à l'époque sur calculatrice (une casio graphique quand j'étais en 6e), et mes premières boucles se faisaient avec des goto et des Lbl.
Mais ça, c'était avant ! J'ai ensuite appris à m'en passer. Jeter un œil sur divers bouts de code compilés avec un désassembleur est aussi très instructif pour étudier ces histoires de boucles...
J'ai jamais ressenti le besoin de faire un GOTO en 8 ans de R.