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

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

[jabbounet]

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

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

[oodini]

Tout cela me parait fort subjectif.

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

[Klaim]

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.

[jblecanard]

Salut

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 ?

[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 )
2. la possibilité d'utiliser le test à choix multiple, rendant de facto le goto inutile

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 ) appelant les fonctions nécessaires, permettant d'avoir un code proche de

Code :

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

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 )

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

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 .

[jblecanard]

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 )
2. la possibilité d'utiliser le test à choix multiple, rendant de facto le goto inutile

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 ) appelant les fonctions nécessaires, permettant d'avoir un code proche de

Code :

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

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.

[oodini]

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.

[Luc Hermitte]

Quoi ?
Le elif est parfaitement indenté.

[Emmanuel Deloget]

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 :

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

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

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