Discussion :

[oodini]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[JolyLoic]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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();
}

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[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.

[3DArchi]

++Indentation adaptée

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

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.

Les enchaînements if/else font qu'il n'y aura pas de tests supplémentaires.

[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.

[oodini]

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

[Luc Hermitte]

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.

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 ? ...

[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 ?

[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.

[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?

[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.

[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.

[jblecanard]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 !

[Flo.]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Neckara]

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 :

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
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

[JolyLoic]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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++.

[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...

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".

[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 ?

[Bousk]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
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.