IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C Discussion :

Que pensez vous du goto [Débat]


Sujet :

C

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Rédacteur

    Avatar de gege2061
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    Juin 2004
    Messages
    5 840
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Juin 2004
    Messages : 5 840
    Par défaut
    Citation Envoyé par Ti-R
    C'est dangereux et cela ne sert à rien

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    //------------------------------------------------------------- 
    int testouinon(void) // renvoit 1 si oui, renvoit 0 si non. 
    { 
                int ch; 
                while(1)
                {
                            ch=getch(); 
                            switch (ch)
                            { 
                                        case 'o': return 1; 
                                        case 'n': return 0; 
                            } 
                }
    } 
    //-------------------------------------------------------------
    Par contre je suis entièrement d'accord que si l'on peut s'en passer autant le faire. Et les goto ne sont pas plus dangereux d'un getch

  2. #2
    mat.M
    Invité(e)
    Par défaut
    Citation Envoyé par argoet
    La regle : Pas de goto dans un programme
    est-ce que tu sais ce que c'est le language assembleur et notamment celui du x86
    A quoi servent les instructions JMP , JGE etc ?? ( language C=assembleur haut niveau )

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    MOV AX,200
    decr_ax:
    DEC AX
    CMP AX,10
    JBE decr_ax
    qu'est-ce qu'on fait ici ??

    La valeur d'un programmeur est inversement proportionnel au nombre de goto que l'on trouve dans son code
    tiens ......tiens .....et dans quel livre cette maxime est statuée ??


    C'est vrai il faut éviter les goto mais parfois c'est bien utile .....
    Dans les exemples du SDK de Direct X il y a utilisation de quelques goto .
    Ils sont vraiment mauvais programmeurs alors chez M$

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Décembre 2005
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2005
    Messages : 12
    Par défaut Le goto peut etre pratique
    Le goto peut etre tres pratique mais doit etre utilisé avec soin. Il est notamment tres pratique pour la gestion d'erreur. Il permet notamment de creer un bloc pour les gestions d'erreurs et de centraliser la desallocation de ressources sur sortie d'erreur. En cas d'erreur il suffit de faire un goto sur un label a la suite duquel on procede à la desallocation et à la sortie de fonction. Cependant une regle pratique est d'éviter de faire un goto qui remonte le flot d'instruction, ce qui peut conduire a des cas délicats.

  4. #4
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Vigneau
    Le goto peut etre tres pratique mais doit etre utilisé avec soin. Il est notamment tres pratique pour la gestion d'erreur. Il permet notamment de creer un bloc pour les gestions d'erreurs et de centraliser la desallocation de ressources sur sortie d'erreur. En cas d'erreur il suffit de faire un goto sur un label a la suite duquel on procede à la desallocation et à la sortie de fonction. Cependant une regle pratique est d'éviter de faire un goto qui remonte le flot d'instruction, ce qui peut conduire a des cas délicats.
    pour la gestion d'erreur, plutot qu'un "goto", j'aurais plutot tendance à créer une fonction englobant un exit() ou un return().

    Pour moi, le goto est inutile :
    chaque cas d'utilisation du goto montre que le bloc d'instructions à "sauter" pourrait/devrait être intégré dans une sous-fonction + mechanisme de test de l'appel.

    Je pense qu'un usage du goto montre qu'on code avant d'écrire l'algo/la spec/etc ... et ça, c'est pas bien :p

    il faut aussi se poser la question du "si j'ai besoin de mettre un goto, est-ce que ça n'est pas parce que mon pgm est mal construit ?"

  5. #5
    Membre émérite
    Profil pro
    Inscrit en
    Juillet 2002
    Messages
    842
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2002
    Messages : 842
    Par défaut
    Démontrer qu'on peut se passer du goto ne me semble pas difficile. A coup d'ajout de if et d'utilisation de variable supplémentaire, on y arrive. Pourtant cette démonstration devrait mettre la puce à l'oreille "On est obligés de créer des variable supplémentaire" et celà est d'autant plus gênant que ces variables n'ont pas de rôle algorithmique.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    for (...)
    {
      for (...)
      {
        ...
        goto FinDeBoucle;
      }
    }
     
    FinDeBoucle:
    Ca, c'est parfaitement intuitif. Sortir d'un bloc, quelque soit son niveau est quelque chose d'intuitif, qu'on pourrait très bien écrire dans un algorithme mathématique désitiné à l'homme et non à la machine. Mais une chose m'a choquée dans les précédents arguments c'est qu'on ait pu insister dans ce genre de cas du fait que le code ne soit pas clair. Le goto ici a bien un avantage : on nomme la sortir de boucle, ce qui permet de comprendre son sens dans l'alogorithme. Toutefois nommer une boucle, c'est très facile. Dans un exemple de boucle non imbriquée :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    for (...) // NomDeBoucleQuelconque
    {
      ...
      break; // Fin de NomDeBoucleQuelconque
    }
    L'utilisation du goto dans le cas de blocs imbriqués est tellement intéressante qu'elle a été intégrée comme structure de langage dans certains langage de manière assez élégante :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    {
      ...
      {
        ...
        break 2;
      }
    }
    Et là le sens que l'on veut donner à l'instruction est parfaitement clair. Une autre structure plus récente utilisée désormais dans de nombreux langages, et qui est accessoirement la plus puissante des structures conditionnelles est la gestion des exceptions. Ces aspects inexistants en C, il ne serait pas dérangeant d'utiliser dans ces cas précis, et uniquement ces cas, l'instruction goto.

    Mais cela ne change rien au danger que représente le goto. L'argument a été répété de nombreuses fois, ce à quoi on a répondu "Ce n'est pas plus dangereux que malloc". Malloc est dangereux, lui aussi, et c'est pour cette raison que les langages les plus récents, non soucieux de la rapidité on préférer cacher au programmeur ces jouets défendus. On ne peut malheureusement pas se passer de l'allocation dynamique, mais on peut se passer de goto, ce qui pèse relativement lourd. On a des techniques pour sécuriser l'allocation de mémoire, des "habitudes" ou des "techniques" de programmation qui permettent de limiter les erreurs. On peut certainement trouver des règles de conduites à l'usage du goto qui permettent d'éviter les dangers.

    "Ne jamais utiliser de goto" est une règle qui a ses qualités. C'est un peu comme le code de la route. On doit faire des vérifications inutiles, mettre le clignotant même quand on est tout seul sur la route. Cela a de nombreux avantage en fin de compte.

    • Etant donné que le débat est compliqué et que tout le monde ne le lira pas, les absents ou ceux qui lisent en diagonal ne comprendront certainement pas les réels dangers et les réels intérêts du goto, et ne connaîtront donc pas les "bonnes" utilisations du goto que ce débat pourra détacher. En conséquent, mieux vaut ne pas les utiliser du tout.

    • On se pose beaucoup de questions quand on programme. Est-ce que le temps perdu à se poser des questions en vaut le bénéfice ? Est-ce que le temps qu'on passe à se demander si on utilise un goto ou non en vaut le code obtenu ? Parfois non, l'usage du goto est clair, ou au contraire, la non utilisation de goto ne complique pas le code. Très souvent sur ce sujet, j'ai vu des solutions avec goto horriblement compliquées et l'auteur aurait, je pense, tout à fait gagné à "programmer sans réfléchir sans goto".

    • Les raisons qui poussent à utiliser ou non un goto sont plutôt complexe. En ce qui me concerne, je n'arriverai pas à les mettres toutes dans ma mémoire. La où c'est ennuyeux c'est pour les dangers du goto. Si je n'arrive pas à me souvenir de tous les dangers du goto (et ils sont trrrès nombreux) il m'arrivera un jour de faire une connerie avec. Autant l'éviter.



    Le principal désavantage du goto est de ne pas être clair du point de vue algorithmique. Coder dans son coin des applications brouillon de quelques centaines de lignes, ce n'est pas très grave. Coder tout seul sur des projets un peu ambitieux, ou coder sur un projet où l'on est pas seul, l'usage d'un code qui n'est pas compréhensible au premier coup d'oeil devient tout de suite gênant. Et le goto a cette mauvaise idée de ne pas toujours être compréhensible au premier coup d'oeil. Sur une fonction de dix ligne, un goto interne à la fonction ne posera pas trop de problème de compréhension. Sur des fonctions un peu complexes, ou en utilisant des labels peu explicites, on arrive très vite à devoir se creuser la tête pour comprendre ce qui est écrit. C'est très traitre quand on débute en programmation et que l'on veut se lancer dans un projet. Quand on programme on a tout ce que l'on veut en tête, on sait ce que l'on fait. Et deux mois plus tard, on peut revenir sur quelque chose que l'on a écrit et ne plus rien comprendre. Se faire peur une fois suffit en général.

    Remplacer le goto par une structure aproprié a un avantage capital déjà précédement énnoncé. On ne sait pas comment il est possible d'arriver à un label donné. Par contre on sait très bien quand l'identation est claire, où un bloc commence et où il s'arrête. L'utilisation des blocs de code permet de voir au premier coup d'oeil la structure d'une portion de code, ce que ne permettent pas les goto. Et c'est son principal défaut.

    Il existe des branchements compliqués auxquels on a certainement tous été confrontés une fois. Une sorte de faiblesse du langage algorithmique qui oblige la répétition de code, où ce qui est mieux, l'usage de fonction. (Qui n'est pas toujours aisé étant donné qu'il faut passer un certain nombre, parfois handicapant, de paramètres)

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    Si Condition1
    | ...
    | Aller à A
    ...
    Si Condition2
    | ...
    | Aller à B
    ...
    A:
    ...
    B:
    (J'espère que je ne me trompe pas)

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    Si Condition1
    | Instructions1
    | Aller à A
     
    Instructions2
     
    A:
    est un truc qu'on a appellé

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    Si Condition 1 Alors
      Instructions1
    Sinon
      Instructions2
    Ici, ce qui pose problème est l'enchevetrement. En analysant les schémas d'exécution

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    Si Condition1
    | Instructions1 
    | Aller à A
     
    Instructions2
     
    Si Condition2
    | Instructions3
    | Aller à B
     
    Instructions4
     
    A:
    Instructions5
     
    B:
    On a

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    Si Condition1
    | Instructions1
    | Instructions5
    Sinon Si Condition2
    | Instructions2
    | Instructions3
    Sinon
    | Instructions2
    | Instructions4
    | Instructions5
    (Je ne sais pas si on peut trouver un problème plus simple)

    Le problème dans ce code est la répétition d'instructions. On utilisera sans trop de problème une fonction Instructions2(); pour résoudre ce problème. Plutôt que de voir une répétition d'instructions, on peut voir une répétition de test de condition :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    Si Condition1
    | Instructions1
     
    Si NON Condition1
    | Instructions2
     
    Si Condition2 et NON Condtion1
    | Instructions3
     
    Si NON Condition1 et NON Condition2
    | Instructions4
     
    Si NON Condition2
    | Instructions5
    qui est une construction mécanique, ou alors pour être plus concis :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    Si Condition1
    | Instructions1 
    Sinon
    |
    | Instructions2
    |
    | Si Condition2
    | | Instructions3
    | Sinon
    | | Instructions4
    |
     
    Si NON Condition 2
    | Instructions5
    Ce code peut aussi être fabriqué de manière mécanique, en utilisant tant bien que mal le schéma du if-else plus haut et en repoussant les "cas non gérés" en dehors de la boucle. Ici, on a effectivement une répétition de conditions, qu'on pourra rendre moins lourde en stockant les résultat des tests dans des variables.

    On peut le faire, mais c'est tout à fait dommage d'y être obligé, d'autant que le C perdrait un aspect : celui d'être un macro-assembleur. On ne pourrait pas écrire en C des solutions aussi rapides qu'en assembleur, alors que cela ne concerne que des instructions courantes en assembleur. S'il est tout à fait possible qu'un code assembleur soit plus rapide qu'un code généré par un compilateur C, parce que le code assembleur utilise des optimisation avoid conditional jump à grands coup de SETcc, MOVcc, SBB, ADC ou encore utilise le parity flag ou autre spécificité du x86 c'est normal, mais que le C se fasse battre par un jeu d'instruction réduit, c'est un outrage ! Le goto permet de garder toute la puissance de l'assembleur. (Ce qui ne sert pas tous les jours, j'en conviens, mais peut servir, notement - et il y en a au moins deux ici - pour ceux qui développent des émulateurs)

    Ces transformations mécaniques peuvent être en revanche, absolument pas algorithmique. L'usage des goto dans l'exemple ci-dessus peut servir pour une éxecution dont la séquence n'est pas si rare que cela. C'est un genre de code emmerdant quand on ne veut ni faire de fonction, ni faire plusieurs fois les même tests. On peut trouver des branchements à tentacule, justifiés algorithmiquement (quoiqu'en les démontrant on utilisera une des formes obtenues mécaniquement) et qui n'ont absolument aucun sens avec une série de if. Mais dans ces cas, l'algorithme est de toute façon pénible à suivre sans crayon à portée de main, et alors le bénéfice du goto n'est que logique au dépend de la lisibilité, et on ne le trouve alors pas avantageux.

  6. #6
    Membre chevronné Avatar de Tchetch
    Inscrit en
    Mars 2002
    Messages
    401
    Détails du profil
    Informations personnelles :
    Âge : 40

    Informations forums :
    Inscription : Mars 2002
    Messages : 401
    Par défaut
    Le débat du goto a commencé avec Edsger W. Dijkstra et son célèbre papier "Go To Statement Considered Harmful" (1968) et a passé par tous les états d'âmes avec des documents nommés " 'Go To Statement Considered Harmful' Considered Harmful" et " ' "Go To Statement Considered Harmful " Considered Harmful ' Considered Harmful " ... Enfin c'est un débat sans fin, mais la plus grosse contre-attaque vient de Donald E. Knuth qui publia "Structured Programming with go to Statements" (1974).

    Donc moralité, goto peut très bien s'utiliser, mais il faut savoir le faire correctement et avec modération (lire "Go To Statement Considered Harmful:
    A Retrospective" pour des exemples.)

    À lire :
    Structured Programming with go to Statements : http://portal.acm.org/citation.cfm?i...FTOKEN=6184618
    Go To Statement Considered Harmful : http://www.acm.org/classics/oct95/
    Go To Statement Considered Harmful: A Retrospective : http://david.tribble.com/text/goto.html
    http://en.wikipedia.org/wiki/Structured_programming
    http://en.wikipedia.org/wiki/GOTO
    http://en.wikipedia.org/wiki/Go_To_S...idered_Harmful

  7. #7
    Christianchristian
    Invité(e)
    Par défaut
    Bonjour,

    Je pense que poser le problème du GOTO revient à poser le problème de la bonne ou mauvaise programmation.

    années 1975 : Apparition des méthodes dites de "programmation
    structurée". (par opposition à la programmation dite
    linéaire : Utilisation plus ou moins intensive de l'ordre
    GOTO).

    Avant cette époque un pgm linéaire "mal monté" (avec une profusion d'ordres GOTO) était difficilement maintenable. Il n'était pas rare de devoir "le casser" pour le ré-écrire.
    Par contre un pgm convenablement "monté" (peu d'ordres GOTO) par un programmeur ayant une approche structurée nécessairement personnelle était facilement modifiable.
    L'arrivée des méthodes de programmation structurées a elle aussi généré certains excès. En effet pour éviter tout GOTO, certains programmeurs structuraient tellement leur programme (sous-prog appelant un sous-sous-prog appelant lui-même un sous-sous-sous-prog......) qu'ils obtenaient le résultat inverse de celui recherché. Leur pgm étaient tout aussi difficilles à maintenir pour peu qu'ils soient conséquents.
    Ces deux attitudes illustrent peut-être le problème posé.
    Les discussions sur le sujet étaient fréquentes et bien entendu les avis partagés et les positions fermement arrêtées.
    Pour ou contre l'emploi du GOTO dans les pgm ?

    En ce qui me concerne je n'ai pas banni cet ordre qui d'ailleurs s'impose plus qu'il ne se choisit. (en gardant à l'esprit que l'on peut toujours faire autrement, mais dans quelles conditions et à quel prix ?).
    Par exemple :
    Un test d'optimisation (IF) accompagné d'un GOTO, programmés au début d'un sous-prog et débranchant la logique d'exécution en fin du même sous-prog si la condition est remplie, me semble raisonnable. Cela permet bien souvent d'alléger la logique principale du pgm en ne l'encombrant pas avec des tests, qui sans être inutiles, n'intéressent pas directement cette logique et par le fait l'allourdissent.

    A noter également que l'ordre GOTO est bien pratique lors de la mise au point d'un pgm, lorsque l'on souhaite "sauter" une séquence suspectée d'être à l'origine de l'erreur recherchée.

  8. #8
    Membre émérite
    Profil pro
    Inscrit en
    Février 2006
    Messages
    624
    Détails du profil
    Informations personnelles :
    Âge : 50
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 624
    Par défaut
    La solution est simple, imaginons très fort que cette instruction n'existe pas!

  9. #9
    Membre Expert
    Avatar de Gruik
    Profil pro
    Développeur Web
    Inscrit en
    Juillet 2003
    Messages
    1 566
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Juillet 2003
    Messages : 1 566
    Par défaut
    Citation Envoyé par Fabrice ROUXEL 1
    La solution est simple, imaginons très fort que cette instruction n'existe pas!
    Ca me ferait une belle jambe

  10. #10
    Membre confirmé
    Inscrit en
    Juillet 2002
    Messages
    168
    Détails du profil
    Informations forums :
    Inscription : Juillet 2002
    Messages : 168
    Par défaut
    Bonjour,

    quand il s'agit d'écrire un intérpréteur , c'est obligé d'utiliser les goto, est ce qu'il y a une autre solution

    Turbo_chess

  11. #11
    Expert éminent
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 394
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 394
    Par défaut
    Je ne vois pas pourquoi ce serait obligé...
    Un interpréteur est généralement plus ou moins un automate d'états fini, qui n'a pas besoin de goto...
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  12. #12
    Nouveau candidat au Club
    Profil pro
    Inscrit en
    Juillet 2007
    Messages
    2
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2007
    Messages : 2
    Par défaut
    J'essaie autant que possible d'éviter les GOTO's mais je ne suis pas intégriste à ce point. Il m'arrive à l'occasion d'intégrer un GOTO RAREMENT deux.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
     
    int testouinon(void) // renvoit 1 si oui, renvoit 0 si non. 
    { 
       int a;
       int ch;
       a=o;
       while(a==0)
       {
          ch=getch(); 
          switch (ch)
          {
             case 'o':a=1;
                        return 1;
             case 'n':a=1;
                        return 0;
             default: break;
             } 
         }
    }
    Vous l'aurez deviné.... j'utilise beaucoup les while!!

  13. #13
    Membre confirmé
    Profil pro
    Inscrit en
    Juillet 2007
    Messages
    106
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2007
    Messages : 106
    Par défaut
    GOTO = porter préjudice à leur fièreté de programmeur, rien de plus.

    Si 'on' a inventé des while et des for, c'est pas pour faire machine en arrière pour utiliser un GOTO, tu vois ce que je veux dire ?

    C'est une question de principe pour ceux qui code.

    PAR CONTRE: si tu fait un programme qui est destiné a être envoyé sur un microcontroleur, et bien avec un GOTO tu peux faire déborder ton stack pointeur car le saut d'adresse peut être trop grand ! donc ton programme bug

    Je vois rien d'autre

  14. #14
    Expert confirmé

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Par défaut
    Citation Envoyé par jack_x4
    PAR CONTRE: si tu fait un programme qui est destiné a être envoyé sur un microcontroleur, et bien avec un GOTO tu peux faire déborder ton stack pointeur car le saut d'adresse peut être trop grand ! donc ton programme bug
    ?

  15. #15
    Nouveau candidat au Club
    Profil pro
    Inscrit en
    Octobre 2007
    Messages
    2
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2007
    Messages : 2
    Par défaut je suis pour le goto
    il me semble qu'à l'origine il n'y a que le goto,

    que le call de la programation structurée est venu plus tard et avec lui les fameux problèmes de pile

    et que le goto présente sur le while et le for l'avantage de la vitesse et l'absence d'utilisation de la pile

    si je devais faire un programme ou je ne souhaite aucune interception de mes adresse de sous routine par la pile, je le ferais completement en goto,

    bien agencés

    maintenant parlons au niveau symbolique

    je trouve que la programation struturée ça fait très petit bourgeois, du genre, vas y l'alu, fait ta routine et reviens pour le jt de 20 heure, et avant de partir met tes chausson dans la pile tu les recupéreras en rentrant

    bon ok, pour les gros programmes ou il y a toujours des problèmes avec le parquet...

    mais le goto, lui c'est la liberté
    je pars et je reviens si nos chemin se croisent encore

    bon d'accord ça met le bordel pour les impots,
    mais que voulez vous nos vies ressemble à nos programmes,
    si nous mettons que des routines dans nos programmes
    nous aurons peut être tendance à ne mettre que des routines
    ...dans nos vies

  16. #16
    Membre éprouvé

    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 116
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 116
    Par défaut
    Goto : la seule utilisation raisonnable que je lui vois est un saut d'une procédure à une autre dans un code assembleur.

    L'employer dans un algorithme itératif me semble réellement être une solution héritée d'une pratique de la programmation ancienne qui ne se veut pas réellement une transcription algorithmique.

    Pour moi ça ressemble juste à une "spécificité" de microcontrôleurs. Bien sûr les branchements conditionnels, c'est bien, mais ça veut dire quoi concrétement ?

    Qui veut apprendre la programmation directement depuis l'assembleur ? Les structures conditions c'est utile non, on peut faire plein de choses avec, on se creuse moins la tête aussi, et c'est plus rapide.

    Goto : outil archaïque. Pourquoi l'utiliser encore, les structures de contrôles des langages évolués se substituent de façon plus élégante et plus efficace, et surtout, plus universelle aux goto.

    Dans tous les cas, je crois bien qu'il est possible d'écrire n'importe quel programme sans Goto, qui est, une instruction héritée de l'assembleur (ancien), pourquoi dire encore les GOTO c'est bien ? Goto ça existe, mais en C ça fait plus rire qu'autre chose. Et bonjour la perte des avantages de la programmation structurée.

  17. #17
    Membre averti
    Profil pro
    Inscrit en
    Février 2005
    Messages
    37
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2005
    Messages : 37
    Par défaut
    Oui je suis d'accord avec toi, mais ce n'est pas dans ce type de circonstances que je compte utiliser goto.

    (on est à l'intérieur d'une boucle while qui lit une par une les lignes d'un fichier texte)

    Si quelqu'un pouvait me donner un code propre et sûr correspondant à celui ci:

    if (ligne[i]==2) //le chiffre correspond au nombre de champs non présents dans la base d'origine
    goto champ2;
    else if (ligne[i]==3)
    goto champ3;
    else{ //traitement du champ1}

    champ2: //traitement du champ2

    if (ligne[i]==1)
    goto champ3;

    champ3: //traitement du champ 3

  18. #18
    Membre Expert
    Avatar de Ti-R
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    Avril 2003
    Messages
    1 683
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2003
    Messages : 1 683
    Par défaut
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    if (ligne[i]==2) //le chiffre correspond au nombre de champs non présents dans la base d'origine 
            fonction_champ2(); 
    else if (ligne[i]==3) 
            fonction_champ3(); 
    else{ fonction_champ1()} 
    if (ligne[i]==1) 
            fonction_champ3();

  19. #19
    Rédacteur

    Avatar de gege2061
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    Juin 2004
    Messages
    5 840
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Juin 2004
    Messages : 5 840
    Par défaut
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    if( ligne[i] == 2 )
    {  /* traitement du champ2 */ }
    else if ( lign[i] == 1 || ligne[i]==3 )
    { /* traitement du champ3 */ }
    else{ /* traitement du champ1 */}

    la même avec les switch:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    switch( ligne[i] )
    {
      case 2:
        /* traitement du champ2 */
      break;
      case 1:
      case 3:
        /* traitement du champ3 */
      break;
      default:
        /* traitement du champ1 */
      break;
    }
    Si les sont peu utiliser c'est qu'ils sont facilement remplassable.

  20. #20
    Membre éclairé Avatar de calogerogigante
    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    Avril 2003
    Messages
    602
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux

    Informations forums :
    Inscription : Avril 2003
    Messages : 602
    Par défaut
    Citation Envoyé par ulukahio
    Oui je suis d'accord avec toi, mais ce n'est pas dans ce type de circonstances que je compte utiliser goto.

    (on est à l'intérieur d'une boucle while qui lit une par une les lignes d'un fichier texte)

    Si quelqu'un pouvait me donner un code propre et sûr correspondant à celui ci:

    if (ligne[i]==2) //le chiffre correspond au nombre de champs non présents dans la base d'origine
    goto champ2;
    else if (ligne[i]==3)
    goto champ3;
    else{ //traitement du champ1}

    champ2: //traitement du champ2

    if (ligne[i]==1)
    goto champ3;

    champ3: //traitement du champ 3
    Là par contre, en effet, je trouve déjà l'utilisation du goto risquée... Très risquée...

    Plutôt d'accord avec les propositions des deux posts au-dessus de celui-ci...

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 8 PremièrePremière 123456 ... DernièreDernière

Discussions similaires

  1. Que pensez-vous des générateurs de doc PHP ?
    Par Nonothehobbit dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 64
    Dernier message: 10/07/2007, 10h17
  2. Que pensez vous de filemaker
    Par thpopeye dans le forum Autres SGBD
    Réponses: 4
    Dernier message: 14/06/2007, 15h20
  3. Que pensez vous du nouveau kernel 2.6 ?
    Par GLDavid dans le forum Administration système
    Réponses: 58
    Dernier message: 02/08/2004, 15h45
  4. [Débat] Que pensez-vous des langages à typage dynamique?
    Par Eusebius dans le forum Langages de programmation
    Réponses: 14
    Dernier message: 16/06/2004, 12h12
  5. Que pensez vous du mariage ASP Flash?
    Par tyma dans le forum Flash
    Réponses: 4
    Dernier message: 09/07/2003, 15h00

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo