goto or not goto

Version imprimable

goto or not goto

Hello,

Je dois me faire un switch sur un string. Comme cela n'est évidemment pas possible, on a généralement recours à des if en cascade.

Toutefois, cela n'est guère agréable de consulter un tel code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 if (myString == "toto") doToto(); else { if (myString == "tata") doTata(); else { if (myString == "titi") doTiti(); } }
Je me demandais si cela n'était pas l'occasion d'utiliser le bon vieux goto :
Code:

1 2 3 4 5 6 if (myString == "toto") { doToto(); goto papam; } if (myString == "tata") { doTata(); goto papam; } if (myString == "titi") { doTiti(); goto papam; } papam : ...
Ne trouvez-vous pas cela plus propre/lisible ?

Cette situation (des else if) est un des cas où j'indente autrement d'à mon habitude, et ne mets pas tous les { que je mets systématiquement sinon
Code:

1 2 3 4 5 6 if (myString == "toto") doToto(); else if (myString == "tata") doTata(); else if (myString == "titi") doTiti();
Ou
Code:

1 2 3 4 5 6 7 8 9 10 11 12 if (myString == "toto") { doToto(); } else if (myString == "tata") { doTata(); } else if (myString == "titi") { doTiti(); }

18/01/2012, 18h51
Klaim
Moi dans ce genre de cas, en partant du principe que les clées sont absolument fixes, je met tout ça dans une map static const et hop.

Reste plus qu'a faire un find.

Si tu n'as pas accès à un compilateur qui permet l'initilizer list, alors tu peux utiliser un fonctor à la construction de ta map static const.
Code:

1 2 3 4 5 6 7 8 9 10 struct BuildMaMapFunctor { // remplis une map avec des clées/valeurs }; void mafunction() { static const std::map< std::string, Something > MAP = BuildMaMapFunctor(); };
Si tu y as accès tu peux faire directement
Code:

1 2 3 4 void mafunction() { static const std::map< std::string, Something > MAP = { { "clée" , Valeur() }, { "autre clée", AutreValeur() } }; };
18/01/2012, 19h00
Lightness1024

c'est pas vraiment plus évident de lire les goto, surtout qu'ils sont en general bannis par coding rules donc n'en voyant jamais c'est tres surprenant de tomber sur un code qui en a et ca déroute la compréhension.

tu peux tres bien indenter tes else if pour faire des lignes. la solution JolyLoic est tres classique et lisible par conséquent.

tes gotos ne servent qu'a éviter deux tests supplémentaires qui vont de toute évidence retourner faux. c'est donc une optimisation, est-elle vraiment necessaire ??? c'est tres tres rarement le cas.

tu peux tout autant faire les ifs sans goto.

sinon solution Klaim : map des foncteurs.
19/01/2012, 07h51
3DArchi

++Indentation adaptée

Citation:

Envoyé par Lightness1024

c'est pas vraiment plus évident de lire les goto, surtout qu'ils sont en general bannis par coding rules donc n'en voyant jamais c'est tres surprenant de tomber sur un code qui en a et ca déroute la compréhension.

Entièrement d'accord. Même si tu identifies un cas où cela simplifierait, goto risque de tellement dérouter d'éventuel mainteneur qu'il faut de toute façon l'éviter

Citation:

Envoyé par Lightness1024

tes gotos ne servent qu'a éviter deux tests supplémentaires qui vont de toute évidence retourner faux. c'est donc une optimisation, est-elle vraiment necessaire ??? c'est tres tres rarement le cas.

:koi: Les enchaînements if/else font qu'il n'y aura pas de tests supplémentaires.
19/01/2012, 08h09
Klaim

En fait je fais aussi juste des if si il y à peu de choix et qu il n y à aucune chance de changer ce nombre. Sinon map ou hash map.
19/01/2012, 10h06
oodini

Vos réponses à l'encontre du goto sont plutôt de nature dogmatique que technique, non ?
19/01/2012, 10h17
Luc Hermitte

Citation:

Envoyé par Klaim

Moi dans ce genre de cas, en partant du principe que les clées sont absolument fixes, je met tout ça dans une map static const et hop.

Voire même une map tabloide où tous les éléments sont contigus.

Citation:

Envoyé par oodini

Vos réponses à l'encontre du goto sont plutôt de nature dogmatique que technique, non ?

La maintenabilité, cela relève de la technique ou du dogme ? ...
19/01/2012, 10h22
oodini

On ne parle pas d'une technique de sioux à base de templates, mais d'un simple goto.

On peut être dérouté une demi seconde, mais je pense qu'on peut trouver bien plus alambiqué dans un code, non ?
19/01/2012, 10h31
Klaim

goto est utile quand il faut sortir d'un ensemble de boucle imbriquées.

Un goto dans le code, c'est l'assurance de ne pas savoir d'où le label à été appelé. Sauf si il n'y a qu'un label et un goto.

Donc c'est bien un problème de lisibilité : tu as plus de chances de comprendre rapidement du code sans un goto qu'avec, et ça peut beaucoup impacter la maintenance puisque c'est du temps perdu.
19/01/2012, 10h36
Neckara

Si le nom du label est explicite, je ne vois pas en quoi c'est déroutant.

C'est comme appeler une fonction sans avoir de RET en assembleur.

Les goto sont très utiles pour sortir de boucles imbriqués ou aller vers un état ''rebut'' d'un automate.

La seule raison de ne pas utiliser des goto, c'est que ce n'est pas très clair.
Mais si c'est utilisé correctement à la place d'une solution illisible, où est le problème?
19/01/2012, 11h03
Luc Hermitte

Le if ... elseif n'est pas une truc illisible. Il ne fait pas exploser les niveau d'indentation -- et il ne présente pas le code smell de 15 if de même niveau qui se suivent.
19/01/2012, 11h05
Flo.

Bonjour,

Je suis un peu du même avis que oodini.

Je n'ai jamais utilisé un seul goto de ma vie. Je dois avouer que le dogme, dans les règles de codage, y est pour beaucoup. Ce dogme me prive de toute liberté quant à l'utilisation d'un goto pour optimiser des codes temps réels par exemple.

Je vois bien souvent des codes à base de template d'un tel niveau d’ingénierie que la lecture d'un code de 20 lignes avec un goto (dans la mesure du raisonnable) semble enfantine à côté. Je trouve que l'argument du manque de lisibilité est un peu surfait.

Bon après j'ai bien compris, qu'un goto risque de passer outre des phases critiques comme la destruction d'objets, etc. Mais il en est de même avec un try/catch par exemple.

Par ailleurs, je trouve que lisibilité d'un code ne se résume pas un bout de code qui utilise un goto ou pas dans une fonction de 10 lignes. Elle vient avant tout d'une bonne modélisation des classes, des relations, etc.

Flo.
19/01/2012, 11h57
jblecanard
Citation:

Envoyé par oodini

Vos réponses à l'encontre du goto sont plutôt de nature dogmatique que technique, non ?

Je suis contre le goto et je trouve que c'est une très bonne remarque. Pour ma part, je suis contre parce que c'est tout simplement inutile la grande majorité du temps. La solution des else if est plus courte à écrire, la preuve :
Code:

1 2 3 if (myString == "toto") doToto(); goto papam; if (myString == "tata") doTata(); goto papam; if (myString == "titi") doTiti(); goto papam;
Code:

1 2 3 if (myString == "toto") doToto(); else if (myString == "tata") doTata(); else if (myString == "titi") doTiti();
Pour zéro optimisation avec goto puisque dès qu'un test est validé, les autres ne sont pas effectués. goto est inutile dans les cas simples et revient à faire du C dans les cas compliqué (n'y a-t-il pas un problème de conception, me dis je alors). De plus, goto rend plus difficile le développement les outils d'instrumentalisation de code qui permettent des vérifications automatiques de code source, choses qui sont systématiquement en place dans l'info industrielle.

Si quelqu'un a un exemple de problème qui est résolu bien plus facilement avec un goto qu'avec autre chose, je suis preneur !
19/01/2012, 12h06
Flo.
Ben le truc classique de sortie des boucles imbriquées par exemple, non ?
Code:

1 2 3 4 5 6 7 8 9 10 for(...) { for(...) { if(...) goto fin; } } fin: // dés-allocation des objets, etc.
Pas besoin de tester une variable à chaque itération ou autre.

Flo.

je ne dis pas que dans ce cas, le goto serait adapté, mais qu'il ne faut pas s'interdire d'utiliser un goto si jamais il nous facilite la vie et rend le code plus lisible.

De toute façon, en assembleur le goto est codé par un JUMP.
Les if/else sont codé à base de CMP (compare) et de JUMP.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
 
int fonction()
{
   if(C1) goto fin;
   if(C2){
          if(C3) goto fin;
          //traitements
   }
   while(C4){
           if(C5) goto fin
           if(C6){
                if(C7) goto fin
                //traitements
                }
    }
 
   fin : //traitements
   return 0;
}
 
//sans GOTO
 
int x = 0;
if(!C1)
{
       if(C2)
       {
              if(C3) x = 1
              else
              {
              }
        }
        if(x != 1)
        {
                  while(x != 1 && C4 && !(C5))
                  {
                              if(C6)
                              {
                                       if(C7) x = 1;
                                       else {
 
                                        }
                               }
                               if(x != 1)
                               {
 
                                }
                   }
 
 
         }
}
//traitement
return 0

19/01/2012, 13h45
JolyLoic
Citation:
Envoyé par Flo.

Ben le truc classique de sortie des boucles imbriquées par exemple, non ?

Code:

1 2 3 4 5 6 7 8 9 10 for(...) { for(...) { if(...) goto fin; } } fin: // dés-allocation des objets, etc.

Pas besoin de tester une variable à chaque itération ou autre.

Flo.
Chaque fois que je me suis trouvé dans cette situation, les boucles étaient directement dans une fonction, et un return était plus approprié qu'un goto. Bien entendu, pour que cette situation soit vraie, il faut :
- Du code qui est massivement RAII (rien à nettoyer manuellement après les boucles)
- Du code où les fonctions ne font pas trop de choses

Mais comme ce sont deux principes que j'applique généralement, ça ne me cause pas de soucis.

Je ne suis pas un extrémiste anti-goto, il se trouve que je n'en n'ai encore jamais eu besoin en C++.
19/01/2012, 13h47
Klaim

C'est le seul cas (et ça dépends fortement du contenu des boucles) ou je me permet goto. Cela dit dans la pratique je ne suis jamais tombé sur ce cas...8O

Dans tous les autres cas, le problème ce n'est pas comment on utilise goto, le problème c'est que si tu lis le code, à partir du label, tu ne peut pas savoir d'où est-ce qu'on est arrivé exactement, sans le voir au runtime. Avec un if tu est certains que les blocs ne peuvent être accédés qu'a partir du code avant le if.

C'est du moins l'argument qui a mis en valeur la programmation dite "structurée" au détriment de goto (voir "goto considered harmful").

Donc goto ça reste utile, mais c'est aussi une garantie que ça sera moins clair (moyennant l'esthétisme du code) que quelques ifs ou qu'un tableau de "cablage".
19/01/2012, 14h26
Luc Hermitte

Pour info, break et continue, je pratique, mais goto je n'en ai encore jamais ressenti le besoin en C++ (tandis qu'en C...)

Au fait. Vous avez vu que le code à coup de goto du début (et qui a été copier-coller) est faux ?
Besoin d'autres arguments contre le goto ?
19/01/2012, 15h09
Bousk
Citation:
Envoyé par oodini

Je me demandais si cela n'était pas l'occasion d'utiliser le bon vieux goto :

Code:

1 2 3 4 5 6 if (myString == "toto") doToto(); goto papam; if (myString == "tata") doTata(); goto papam; if (myString == "titi") doTiti(); goto papam; papam : ...

Ne trouvez-vous pas cela plus propre/lisible ?
Disons que, au mieux ton premier if est bon, sinon tu passes directement en papam :mrgreen:
Mis à part ce qui est sûrement une simple erreur de recopie, un goto dans ce cas-là ne gène pas la lisibilité amha, mais une succession de if/else if non plus et sera plus habituelle.

Le cas de la double(et plus) boucle imbriquée me semble être vraiment un des rares cas où le goto est très pratique. Que je n'ai rencontré qu'une unique fois pour ma part, et uniquement à la lecture par curiosité, je ne suis pas intervenu sur le code en question.
19/01/2012, 16h05
oodini

Tout cela me parait fort subjectif.

Pour en pas violer le dogme relatif aux goto, on viole le dogme relatif aux indentations...
19/01/2012, 16h25
Luc Hermitte

Quoi ?
Le elif est parfaitement indenté.
19/01/2012, 16h52
Klaim

Citation:

Envoyé par oodini

Tout cela me parait fort subjectif.

Pour en pas violer le dogme relatif aux goto, on viole le dogme relatif aux indentations...

Perso je suis pret a utiliser goto si besoin, mais comme dit je n'en ai finalement jamais eu besoin, surtout pas dasn ce cas là.

Dans tous les cas rien ne t'empêche de l'utiliser et de voir par l'expérience si ça valait le coup.
19/01/2012, 18h21
jblecanard

Salut

Citation:

Envoyé par oodini

Tout cela me parait fort subjectif.

Pour en pas violer le dogme relatif aux goto, on viole le dogme relatif aux indentations...

Allons oodini, le choix d'indentation n'a aucun impact sur le sens du code.

Globalement, ce qui ressort des discussions est que goto n'est utile que dans de très rares cas. Dans le tien, il ne t'apporte rien : le code n'est pas plus lisible, pas plus efficace, pas plus sécurisé. Pire : tu ne peux pas utiliser les one liners comme tu l'as fait, tu es obligé de mettre des accolades, ce qui n'est pas le cas dans le elif.

Je ne vois ce qu'il y a de subjectif là dedans, ne sont-ce pas des faits ?
19/01/2012, 20h55
koala01
Salut,

Pour le problème de base ayant provoqué la question, je crois que je commencerais déjà par essayer de voir s'il n'y a vraiment pas moyen d'abandonner les chaines de caractères au profit de valeurs numériques et cela pour les deux raisons classiques qui sont
1. le gain de performances (ou plutot la perte de performance qu'occasion la comparaison entre chaines de caractères :D)
2. la possibilité d'utiliser le test à choix multiple, rendant de facto le goto inutile :D
S'il n'y a vraiment pas moyen d'éviter la comparaison de chaines de caractères, je me demande si je ne m'orienterais pas carrément vers une map dont la clé serait la chaine de caractères et la valeur un pointeur de fonction (ou mieux: un pointeur sur foncteur :D) appelant les fonctions nécessaires, permettant d'avoir un code proche de
Code:

1 2 3 std::map<std::string, Functor *>::const_iterator it = lamap.find(lachaine); if( it!= lamap.end()) it->second();
Cela aurait, en plus, l'avantage d'éviter de comparer la chaine à rechercher avec l'ensemble des chaines existantes, l'alogrithme de recherche dans une map étant dichotomique ;)

Mais pour répondre à l'interrogation initiale concernant le goto (quand meme :D)

J'avoue sans honte ne vraiment pas être un ardent défenseur du goto, parce que j'estime vraiment qu'il cause énormément de tord à la programmation structurée.

Il faut dire que, quand un prof qui fait une fois et demie à deux fois ton poids te menace de te jeter par la fenêtre si tu utilises goto, ca aide à prendre l'habitude de s'en passer :D

Mais, plus sérieusement, je n'ai jamais eu besoin d'utiliser goto, meme quand je programmais en C ou en Cobol, et au dela du simple dogme, je trouve que c'est comme beaucoup de chose: il se peut qu'il soit utile dans certaines circonstances très particulières, et à condition qu'il soit utilisé avec parcimonie, mais, à moins que ce ne soit vraiment la meilleure (ou plutot la moins mauvaise) des solutions envisageables, il est quand meme beaucoup plus sur de l'éviter.

Ne serait-ce que parce que, s'il est utilisé de manière impropre ou inadaptée, on a tôt fait de se retrouver avec un "code spagetti" dans lequel il devient de se retrouver ;).
20/01/2012, 11h31
oodini

Citation:

Envoyé par jblecanard

Globalement, ce qui ressort des discussions est que goto n'est utile que dans de très rares cas. Dans le tien, il ne t'apporte rien : le code n'est pas plus lisible, pas plus efficace, pas plus sécurisé. Pire : tu ne peux pas utiliser les one liners comme tu l'as fait, tu es obligé de mettre des accolades, ce qui n'est pas le cas dans le elif.

Effectivement, cette modification de code rend l'utilisation du goto moins pertinente.
20/01/2012, 11h35
jblecanard
Citation:
Envoyé par koala01

Pour le problème de base ayant provoqué la question, je crois que je commencerais déjà par essayer de voir s'il n'y a vraiment pas moyen d'abandonner les chaines de caractères au profit de valeurs numériques et cela pour les deux raisons classiques qui sont

le gain de performances (ou plutot la perte de performance qu'occasion la comparaison entre chaines de caractères :D)
la possibilité d'utiliser le test à choix multiple, rendant de facto le goto inutile :D
S'il n'y a vraiment pas moyen d'éviter la comparaison de chaines de caractères, je me demande si je ne m'orienterais pas carrément vers une map dont la clé serait la chaine de caractères et la valeur un pointeur de fonction (ou mieux: un pointeur sur foncteur :D) appelant les fonctions nécessaires, permettant d'avoir un code proche de

Code:

1 2 3 std::map<std::string, Functor *>::const_iterator it = lamap.find(lachaine); if( it!= lamap.end()) it->second();

Cela aurait, en plus, l'avantage d'éviter de comparer la chaine à rechercher avec l'ensemble des chaines existantes, l'alogrithme de recherche dans une map étant dichotomique ;)
Oui et trois fois oui ! On ne le dira jamais assez.

J'y vais de mon avis personnel :

1/ goto en C++ est inutile.

Dans le cas de l'OP, une simple gestion à base de if (...) else if (...) fonctionne très bien, donc je ne vais pas revenir dessus.

C++ offre la possibilité d'utiliser RAII pour contrôler la gestion des ressources. En cas d'erreur d'exécution, les ressources seront libérées automatiquement si on sort de la fonction. RAII, auquel on ajoute l'écriture de code résistant aux exceptions permet de s'assurer que l'état en sortie d'une fonction qui a échoué est le même qu'en entrant dans cette fonction.

Au cas où l'on souhaite sortir de boucle imbriquées, et étant donné que l'algorithme en O(n^2) est nécessairement assez important (en tout cas, plus qu'un appel de fonction), autant écrire l'algorithme dans une fonction séparée et provoquer la sortie de la fonction. Ca permet en outre d'éviter de réécrire le même code 40 lignes plus loin (parce que les algos nécessitant des boucles imbriquées ont tendance à se répéter) et de profiter de RAII pour gérer les cas d'erreur.

Enfin, la remontée d'erreur peut se faire vie l'utilisation d'exceptions.

C++ fournit tous les outils permettant de se passer de goto, sans impact notable sur le code lui-même. Autant les utiliser.

2/ goto en C peut être utile, à condition de savoir ce qu'on fait.

En fait, C offre des outils limités. Dans le cas ou l'on souhaite sortir d'une boucle imbriquée, je répéterais ce que j'ai dis plus haut. Mais on a un problème lorsqu'on souhaite gérer efficacement les erreurs.

C n'offre pas la possibilité d'implémenter RAII. Du coup, il peut être utile d'utiliser goto avec parcimonie lorsque le besoin s'en fait sentir. Ceux qui se sont lancé dans l'étude du code source du kernel linux peuvent se rendre compte de la fréquence d'utilisation de goto pour traiter les cas d'erreur.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 static struct my_driver driver_obj; void my_driver_init() { if (my_driver_probe() < 0) return -ENOENT; driver_obj.mem = kzalloc(...); if (!driver_obj) return -ENOMEM; if (my_driver_fetch_pci_registers(&driver_obj) < 0) goto err_fetch_registers; if (my_driver_send_reset(driver_obj) < 0) goto err_reset; /* encore plein de code qui, à chaque étape, peut échouer */ return 0; err_reset: my_driver_restore_pci_registers(driver_obj); err_fetch_pci_registers: kfree(driver_obj.mem); return -1; }
Sans passer par des goto, le code devient vite difficilement lisible - car à chaque étape, il faut répéter le code de librération des ressource en cas d'échec. La duplication mène à la possibilité de bug dans ce cas, et ne facilite pas la maintenance. Une autre solution serait d'écrire un code ressemblant à :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 if (my_driver_probe() == 0) { driver_obj.mem = kzalloc(...); if (driver_obj.mem) { if (my_driver_fetch_pci_registers(&driver_obj) == 0) { if (my_driver_send_reset(driver_obj) == 0) { ... return 0; } my_driver_restore_pci_registers(driver_obj); } kfree(driver_obj.mem); } }
Mais dans ce cas, on diminue sensiblement la lisibilité (d'autant plus que le style de code nécessite une tabulation de 8 espaces). Quelques uns auront pensé à une autre solution : l'utilisation de fonctions plus simples, qui sont appelées en cascade. Sauf qu'il ne faut quand même pas oublier qu'on est dans un kernel d'OS, et que tout appel de fonction a un coût (et qu'il y a d'autres considérations à ne pas perdre de vue, comme le linker interne du kernel qui va libérer la mémoire prise pas les fonctions du segment __init une fois ce code exécuté, ou ne pas charge le code du segment __exit si le driver est intégré au kernel ; il y a plein de subtilité, mais le gros point noir des appels de fonctions reste quand même le cout de l'appel en lui même).

21/01/2012, 16h00
jabbounet

Citation:

Envoyé par oodini

Vos réponses à l'encontre du goto sont plutôt de nature dogmatique que technique, non ?

Oui c'est souvent dogmatique, Cependant pour avoir connu des programmes remplis de goto dans des langages assez anciens je pense qu'il vaut mieux les laisser se reposer en paix.

Comme souvent c'est l'abus qui est gênant.....