La portée de ton goto se limitera à ton .c alors qu'une fonction pourra etre rangée au propre et appelée depuis n'importe autre source, bref un vrai code modulaire.

+1 avec BadMax...

Bon allez c'est trolldi donc je me lâche... Si en même temps vous utilisez des langages du moyen-âge... Bizarrement en C# j'ai jamais ressenti le besoin d'utiliser de GOTO d'aucune sorte.

Ben vois-tu, je ne suis pas (du tout) d'accord avec toi.
Je pense que, comme beaucoup, tu es dans le matraquage des universitaires qui n'ont jamais codé, et qui considère que "on peut faire quelque chose de mauvais avec, donc c'est mauvais".

Les mêmes personnes haissent le C, parcque "tu peux faire de l'allocation mémoire manuelle, et donc des segfault / overflow, et donc c'est mauvais".

Alors pour info je n'ai pas de formation universitaire en informatique (ni même école d'ingénieur d'ailleurs) je suis totalement autodidacte (et je suis loin de me considérer comme un cador...). Ma formation informatique s'est limité à du Pascal, du C et du Java en application à du calcul numérique (donc essentiellement des algorithmes mathématiques qu'on finissait par implèmenter). Autant te dire, que nos profs étaient plus matheux qu'informaticiens (à part un mais il était alcoolique et officier de sécurité) et que du coup ce genre de considération leur passait au dessus de la tête.

Mon avis sur le GOTO s'est forgé avec "l'expérience"... Mais effectivement je suis plutôt d'accord avec le fait que ce n'est pas intrinsèquement mauvais, c'est juste que dans 90% des cas, c'est très mal utilisé. Après mon expérience est relativement limitée vu le nombre de projets sur lesquels j'ai bossé. Peut-être que dans quelques années, je ferai l'apologie du GOTO qui sait (mais j'y crois pas en le disant )

En Java il n'y a pas d'instruction goto, à ma connaissance.
En C++ et C#, c'est vrai que le système d'exceptions fournit une alternative plus adaptée à la plupart des cas d'usages du goto. Mais en C, son usage reste courant...

Bien entendu, on peut rendre du code illisible avec. Mais on n'a pas non plus besoin de l'instruction goto pour atteindre ce but: un peu d'arithmétique incompréhensible sur les pointeurs ou une surcharge d'opérateurs infâme permettra de rendre un code imbitable à coup sûr.
Et cet argument peut marcher dans les deux sens... comme l'a montré jack, il existe des cas où un goto est beaucoup plus clair que de multiples niveaux d'imbrication.

En tout cas, il faut quand même savoir que l'usage du goto en C est loin d'être rare en pratique. Le noyau Linux en est d'ailleurs truffé.

C'est rigolo, quand j'avais suivi une pseudo formation AFPA en 2006/2007, le formateur insistait lourdement sur le fait qu'il ne fallait jamais utiliser de GOTO.

Après, vu qu'il était très mauvais, bloqué dans un modèle des années 80, et qu'il passait la moitié de sa journée à tenir un camion à pizza pour arrondir sa paie au lieu de nous former, je n'ai jamais su s'il fallait tenir compte de la seule chose qu'il a essayé de nous apprendre.

J'aime bien cette approche donnée en exemple en Ada, langage utilisé en aéronautique et spatial sur de nombreux systèmes embarqués. Ada est normalement considéré comme exemplaire en terme de "propreté" à l'écriture et l'exécution (avec les débordements qu'on connait).

http://en.wikibooks.org/wiki/Ada_Programming/Control#Isn.27t_goto_evil.3F

procedure Use_Return is
begin
   Do_Something;

   if Test then
      return;
   end if;

   Do_Something_Else;

   return;
end Use_Return;
procedure Use_Goto is
begin
   Do_Something;
 
   if Test then
      goto Exit_Use_Goto;
   end if;

   Do_Something_Else;

<<Exit_Use_Goto>>
   return;
end Use_Goto;

Because the use of a goto needs the declaration of a label, the goto is in fact twice as readable than the use of return. So if readability is your concern and not a strict "don't use goto" programming rule then you should rather use goto than multiple returns. Best, of course, is the structured
approach where neither goto nor multiple returns are needed:

De toutes façons, l'avenir est au Windev :

// Exécution d'un thread avec passage de paramètres
sDate est une chaîne
sDate = DateSys()
// Exécution du thread
ThreadExécute("THREADNAME", threadNormal, "pExecReq", sDate)

// Détail de la procédure "pExecReq" qui attend une date en paramètre d'une requête
PROCEDURE pExecReq(sDate)
SI HExécuteRequête(Sup_Date, hRequêteDéfaut, sDate) = Faux ALORS
        Erreur(HErreurInfo())
SINON
        HLitPremier(Sup_Date)
FIN
Traduction des instructions en français littéral, autorisation des accents dans les variables, le rêve de tout développeur !
</trolldi>