switch de string

**Marcou** · 14/03/2005, 12h19

Salut,

j'ai lu un peu partout qu'il est impossible de faire un switch de string. Je voudrai poster une solution pour contourner le problème. Voici le code (compile sous g++ 3.3):

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
 
#include <iostream>
#include <string>
#include <map>
using namespace std;
 
int main(int argc, char *argv[]){
/*************************** 
* Petit parseur decommande
* G. Marcou
***************************/
    typedef map<string,int> StrInt;
    StrInt coms;
    string com;//Inutile, pour montrer que c'est bien une variable string
 
// Definition de la map
    coms["-to"]=0;
    coms["-ti"]=1;
 
//Boucle sur les options
    while ((argc > 1) && (argv[1][0] == '-')) {
// Trouver l'entree de la map qui correspond au string
        com=argv[1];//On peut utiliser argv directement
	map<string,int>::const_iterator i = coms.find( com );
// Blinder le programme
	if(i == coms.end()){
	    test(argv,argc);
	    cout << "Unknown parameter" << endl;
	    return(1);
	};
// Le fameux switch... 
	switch (i->second){
            case 0://-to
		--argc;
		++argv;
		cout << "toto" <<endl;
		break;
            case 1://-ti
		--argc;
		++argv;
		cout << "titi" << endl;
		break;
	};
    };
    return(0);
}

C'est une solution que je n'ai pas rencontrée auparavant. J'aimerai savoir si elle pose en soi un problème qui fait qu'on lui préfère des if imbriqués (solution le plus souvent proposée, je crois).

Ciao!

**bigboomshakala** · 14/03/2005, 12h50

Comment tester des chaînes de caractères dans un bloc switch ?

Enjoy yourself !

**Marcou** · 14/03/2005, 14h56

Salut,

c'est bien de cette FAQ que j'ai dérivé mon exemple. Mais la solution de la FAQ est différente dans la mesure où elle consiste à appeler des fonctions pour chaque couple clef/valeur de la map. En dehors du fait qu'il y a donc un appel de fonction pour chaque chaine traitée, il ne me semble pas possible de reproduire l'omission du 'break' dans le switch. En somme que deux ou plusieurs chaines (ici deux ou plus case du switch) partagent une partie des instructions.

Pour en revenir à ma question, un de mes collègue m'a expliqué que la solution que j'ai proposé produit un code très "sale", contenant beaucoup trop d'instructions pour le résultat souhaité. Au contraire, un ensemble de if imbriqués reste quasiment inchangé au cours de la compilation...

De mon point de vue tout commentaire est le bienvenue pour y voir plus clair...

Ciao!

**Aurelien.Regat-Barrel** · 14/03/2005, 16h33

l ne me semble pas possible de reproduire l'omission du 'break' dans le switch

ben il suffit d'associer 2 fois la même fonction à 2 string différentes.

La map plus sale que des if...else imbriqués... Ca produit peut être plus d'instructions, mais ça demande moins de lignes de code (sauf pour de tous petits exemples) et c'est bien ces lignes de code C++ qui comptent, et pas le code asm généré derrière; surtout que la map est plus rapide que des if...else imbriqués.
Un nombre élevé de if...else imbriqué est plutôt considéré comme du mauvais design => comme du code sale, à moins d'avoir 2 ou 3 strings à tester. Car certes coder "le moteur" est un peu plus long, mais par la suite c'est bien plus souple et élégant, alors qu'inversement les imbrications de if...else rendent le code de plus en plus obscure.
Si c'est pour traiter les paramètres en ligne de commande, inspire toi plutot de choses déjà faites, comme boost::program_options.
http://www.boost.org/doc/html/program_options.html
ou encore:
http://www.codeproject.com/cpp/#Command+line+processing

**Marcou** · 14/03/2005, 18h21

Merci pour ces précisions. Si j'ai bien compris, l'utilisation de la commande switch doit etre privilégiée quand elle est accessible. Dans l'exemple que j'ai fourni auparavant, l'utilisation de la map n'induit pas ou très peu de déterioration des performances vis-à-vis de if...else imbriqués. En revanche, le code gagne en clarté et concision.

Pour la question du break manquant, je pensais à une situation de ce type:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
swith(opt){
   case 0:
      cout << "Si j'ai 0..."
   case 1:
      cout << "J'ai 1";
      break;
   default:
      cout << "defaut";
      break;
}; cout << endl;

Quand

Code :

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

opt=1

, le programme exécute un code spécifique à 1, mais quand

Code :

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

opt=0

le code spécifique à 0 ET à 1 est exécuté.

C'est vrai que c'est lors de la conception d'une interface utilisateur que j'en suis venu à me poser ces questions. Je ne connaissais pas boost. Je vais jeter un coup d'oeil. Mais ce type de questions peut avoir des applications par exemple dans le design de modules pour lire de multiples formats en bio/cheminfo. On peut trouver un intéret à cette syntaxe également dans l'alignement de séquences... Un exemple concret serait l'ajout d' atomes d'hydrogène aux différents type d'acides aminés définis par leur code 1 lettre ou 3 lettre ou leur nom entier. Ces données provenant généralement de la lecture d'un fichier, elles se trouvent etre habituellement stockées dans un tableau de char ou une variable string.

Bon ben j'ai appris des trucs aujourd'hui!

Ciao!

**Luc Hermitte** · 14/03/2005, 20h45

Hello

Envoyé par Marcou

a- Si j'ai bien compris, l'utilisation de la commande switch doit etre privilégiée quand elle est accessible.
b- Dans l'exemple que j'ai fourni auparavant, l'utilisation de la map n'induit pas ou très peu de déterioration des performances vis-à-vis de if...else imbriqués.
c- En revanche, le code gagne en clarté et concision.

a- C'est plutôt le contraire. switch n'est pas évolutif et va un peu à l'encontre du principe qu'un programme devrait être ouvert aux évolutions et fermé aux modifications.

b- euh ... c'est plutôt les if qui devraient être pénalisants sur un nombre non ridicule de cas différents. Si la liste de cas n'est pas appelée à évoluer, on peut accélérer le traitement avec un vecteur trié et std::binary_search -- enfin, inutile d'optimiser ce genre de trucs tant que l'intérêt n'a pas été prouvé.

c- Tout à fait, les map améliorent tout ça. Ce qui induit une meilleure maintance.

Enfin, si il faut faire des parseurs, il y a d'autres techniques plus adaptées.

**Marcou** · 15/03/2005, 09h43

Salut,

je ne comprend pas bien en quoi une instruction switch rend le code plus difficile à faire évoluer?

Pour le point b, une série de if...else est inefficace parce qu'elle contraint le code à faire ses tests séquenciellement. Sur quelles bases se font les recherches dans une map ou une instruction switch?

Ciao!

**Aurelien.Regat-Barrel** · 15/03/2005, 10h04

La map est triée en interne. Ca augmente le coup d'une insersion, mais la recherche est bien plus rapide.

**Laurent Gomila** · 15/03/2005, 13h55

Sur quelles bases se font les recherches dans une map ou une instruction switch?

Habituellement la map est organisée en arbre binaire, d'où une recherche en temps logarithmique. Pour le switch, le compilo construit une table de saut, donc la recherche est en temps constant. Mais bon, cela a rarement de l'importance.

**Luc Hermitte** · 15/03/2005, 19h36

Envoyé par Marcou

je ne comprends pas bien en quoi une instruction switch rend le code plus difficile à faire évoluer?

Je vais faire parler d'autres que moi, et voici un résultat vite cherché et vite trouvé sur google avec <<"open close principle" switch>>
http://www.eventhelix.com/RealtimeMa..._principle.htm

Rajouter de nouveaux cas n'implique pas de modifier le code. Juste de rajouter "ailleurs" des choses qui par addition font évoluer l'ensemble.

**Marcou** · 15/03/2005, 20h24

Merci pour tout.

Ciao!

switch de string

SL & STL C++

Discussions similaires

Partager

Partager