je trouve ca bien utile, j en utilise quelque un dans mon programme, est ce recomende ?
 
je prefere demander avant de poster mon bout de code...

c'est très mal

pkoi ?
(si c etait serieux)

d'un point de vue purement algorithmique, il n'y a rien de mieux que le goto pour destructurer un programme

 
le longjmp est peut etre encore un cran au dessus

à mon avis c'est surtout inutile...et ca peut être dangereux si c'est mal utilisé!

le goto est une rémininescence d'un style de programmation ancien qu'il faut absolument éviter aujourd'hui, dommage que l'instruction elle-même existe encore
 
Et en effet, un seul goto suffit à démolir la logique d'un algorithme (et éventuellement sa stabilité).

 
En java, le mot clef goto est dans les mots clefs du langage, mais il ne fait rien (enfin si, une erreur de compilation)

par ce qu'en C++ on a tous les outils nécessaires pour faire sans, ne pas casser le fils d'éxécution. en C on à pas les execptions ni les destructeurs, donc le traitement d'erreur est nettement plus long à effectuer, donc y utilise souvent le goto. mais en C+, jamais, ça n'est d'aucune utilité.

ok merci je ferai autrement alors

Je rajouterai aussi que si tu penses à la personne qui va un jour relire ton programme... et bien je peux te garantir que si elle doit essayer de s'en sortir avec des goto elle est pas dans la merde...
 
Je faisais des goto à l'époque du basic. Avec les technologies actuelles, un goto est TOUJOURS remplacable.

Le goto est parfois tentant, surtout pour sortir d'une série de boucles imbriquées (le break ne sort que de la boucle la + interne; certaines langaes comme Ada permettent de nommer le boucler ce qui est bien pratique mais pas le C ).
Dans le but d'éviter le goto en C, j'ai déjà croisé çà :
 
on a ça :

 
sachant que ok peut dépendre d'une erreur ou non (pas besoin de faire les traitements 3 et 4 ...).
On est tenté de placer un goto :
 

 
Après tout, 5 ou 6 imbrications c'est pas tellement plus lisible qu'un goto, surtout un goto en avant.
Alors j'ai croisé cette alternative :
 

mouef... je pense plutot à une simulation d'exception, traitement d'erreur: en fonction de la ou l'erreur se produit, on a un certain nombre de taches de nettoyage à effectuer. genre

 
voilà le genre de structure qu'on trouve souvent en C par exemple
 
alros bien sur, on peut à chaque erreur, insérer le code qui convient, mais ça revient à dupliquer autant de fois qu'il y a de situation. avec le goto, on a quelque chose de centraliser, de tres clair et tres efficace

 
A mon avis c'est n'importe quoi parce que ton break
ne fait pas autre chose qu'un goto.. Sauf que dans ce cas c'est moins clair et on sait pas trop ce que le while(false) fait la a part pour faire beau (et éviter un goto !).
 
Perso j'ai utilisé de temps à autre des goto dans mes programmes en C++ et dans ce cas, la solution avec goto est plus simple et surtout plus claire. De plus contrairement au setjmp/longjmp
le goto est correct meme en C++ et il y a des règles évidentes à respecter (On ne saute pas à l'intérieur d'une boucle, etc..).
 
Je ne suis apparemment pas le seul à penser ça puisque dans toutes les boites ou j'ai bossé, j'ai croisé un ou deux goto dans les source codes. Ici c'est meme pire puisqu'on éxecute du code assemblé à la volée !
 
Bref pour répondre à ta question:
Non le goto n'est pas une erreur mais OUI si tu l'utilises à tire larigot dans toutes tes fonctions ou si ton programme n'est qu'un immense spaghetti avec que des goto alors tu as un probleme.
 
LeGreg

Je précise juste que ce n'est pas "mon break" et que je n'ai jamais utilisé cette structure. Je l'ai croisée c'est tout, et c'est vrai que j'ai pas pigé de suite que le but était d'éviter un goto.
Je sais plus qui a écrit un article où il démontre l'utilité du goto. Si quelqu'un connaît cet article et a un lien ...
 
Pour l'exemple de Taz, moi j'ai plutôt croisé ce genre de chose :
 

 
Maitenant, si tu déplaces dans une fonction Error() le code du goto (libération puis renvoie du code d'erreur), tu peux te passer du goto :

 
Il y a l'article classique Go To Statement Considered Harmful et une réponse 'Goto considered harmful? considered harmful. On peut trouver beaucoup de discussions sur le sujet notamment en faisant une recherche dans les newsgroups.
 
Pour ma part, j'ai un réel problème avec les gotos. Au point que j'en viens à utiliser des suites de ifs pour éviter d'en utiliser.
Mais bon, en C++ on a les exceptions qui remplacent les gotos
 
edit:
Trouvé un lien pour 'Goto considered harful' considered harmful.

le greg > tu te rends compte du nombre de paramètre à envoyer? cette solution est dans la pratique infaisable

Je suis d'accord. Le goto, même quand il est justifié, ça fait quand même grincer des dents. C'est comme le char * en C++, des fois il a sa place, mais ça fait tiquer ...

Parfois un goto sera la meilleure solution à une structure de code complexe, mais c?est rare.
 
 

C?est bien un saut comme le goto? mais en beaucoup plus sûr :
-break/continue font obligatoirement référence la première boucle/switch englobante, alors que le goto pourrait aller n?importe ou dans la fonction.
-La fin de cette boucle ne peut être atteinte que naturellement ou par break, alors qu?une étiquette pourrait être une destination depuis n?importe où dans la fonction.
 
 
Bref, le code contenant des embranchements est isolé dans un bloc, c?est structuré et sans surprise.
Ajoutons que cela dispense de choisir un nom d?étiquette, et du risque de s?y tromper ou de mal la placer.
 
Et une fois qu?on sait cela et qu?on le pratique, ça devient aussi plus clair comme ça?

<mode humour="incompréhensible">
Nan, fait des appels avec continuation c'est mieux !
http://www.swiss.ai.mit.edu/projec [...] ode92.html
 
Ah bah oui mais en C on peu pas faire un appel sans faire grossir la pile !
</mode>

dans une fonction on peut utiliser return aussi qui est une sorte de goto et qui permet de sortir de tout...
 
 

Oui, j'avais utilisé une extension pas standard pour faire ca une fois : les fonctions imbriquées de gcc (pour pas polluer l'espace de nom du fichier). C'est très utilisé en fonctionel impur.
 
c'était pour etre sur que dans tous les cas, un fichier ouvert soit fermé (un truc a la ensure: de smalltalk).

Personnellement, je décomposerais le programme en sous programme :
 

 
Le seul problème, c'est si les traitements manipulent plein de données, il faudrait alors les passer en paramètres à la fonction traitements(...) mais si c'est du C++ et que tous les paramètres sont des éléments de la classe, y'a pas besoin de les passer en paramètre, ces 2 méthodes les connaîtront.

Je pige pas trop l'utilité du truc ... si procedure_qui_contenait_les_traitements se contente d'appeler traitements, je vois pas à quoi elle sert. Mais le problème n'est pas là : il s'agit de libérer certaines ressources en fonction du moment ou a eu lieu l'erreur. Plus on avance, et plus il faut libérer des ressources. Et a chaque fois c'est le même code de libération. Pour éviter de dupliquer 5 fois le code, un goto est utilisé.

Ben là, c'est qu'un exemple, dans la proc qui appelait les traitements, il peut y avoir d'autres trucs avant ou après (genre une initialisation avant traitement puis un affichage du résultat ou une gestion de l'erreur retournée). Au pire, ça peut être main() cette procédure.
 
M'enfin tout ça sert à sortir facilement avec des RETURN (propre) plutôt qu'avec des GOTO (sale) ou des BREAK (pas clair).