Je sais pas si ca existe pour tous les langages...
 
en algo ca donne :  
 

 
Vous préférez quelle méthode, et pourquoi ?

[jfdsdjhfuetppo]--Message édité par Jubijub--[/jfdsdjhfuetppo]

boaf depends des cas, generalement si il y a beaucoup de choix un switch/case est ptet mieux, si y'en a juste 2/3 if/else fera tres bien l'affaire.....

ca depend du langage
en Caml, le pattern matching trop fort.
En C/C++, ben tu ne peux faire un switch..case
que sur des types entiers donc c'est vite vu..
 
LEGREG

visuellement le selon cas est mieux, mais niveau compilation c'est moins bien il me semble...
 
@++

Le Case  

 
En c++ tu peux faire des swith/case sur des string aussi.

Mais sinon pour répondre à la question original, le case est bien plus lisible, flexible et permet au compilateur de choisir plus facilement la meilleur approche suivant le système.

Correct, par contre en Java on peut pas, et c'est bien embêtant

oui mais bon, si je devais dire tout le bien que je pense de java, je serais grossier

gizmo a écrit a écrit : oui mais bon, si je devais dire tout le bien que je pense de java, je serais grossier

t'es pas sympa, perso, je commence à apprécier, ne serait-ce que pour la portabilité

Ben moi je préfère des fonctions virtuelles et des classes dérivées

arf vous m'avez fait peur sur le C++ ...
 
même en script VDbase 5.5 on peut le faire ...c d'ailleurs tout chelou comme language, c  un mélange de Dos shell, de basic et de pascal...

??

Le case, c'est fait pour et en plus c'est clair.  
 
Le if imbriqué, ça allait au temps du basic...

_gtm_ a écrit a écrit : Ben moi je préfère des fonctions virtuelles et des classes dérivées

 
Bien vu, moi aussi  

Pour un switch sur une string : je pense pas. Mais voici une petite proposition :  
 
On prend une fonction qui à une chaine associe un nombre.
Comme on écrit des cases, on connait deja toutes les possibilités, donc on peut vérifier si la fonction donne bien un résultat différent pour chaque possibilité.
Et ensuite on fait le case sur les nombres calculés.
 
En gros, je propose d'utiliser une fonction de hachage et de faire le case sur le résultat. Il se peut même qu'en perf on y gagne, selon la fonction utilisée, car il n'y a qu'une opération sur des chaines à faire

le probleme du case, c'est que tu ne peux comparer qu'a des constantes

voir plus haut, ca dépend des langages

c vrai que tu peux faire une procédure de translation en string pour comparer...

 
tu as un exemple de code qui compile??
 
LEGREG

me suis trompé de nom, c'est pas des string, mais des char, honte sur moi

 
Moi j'avais entendu dire le contraire...
Ce qui semblerait logique, le compilateur crée son if de la manière la plus optimisée possible.
D'ailleurs un truc intéressant:
if expression then
  valeur := 1
else
  valeur := autrechose;
 
Il arrive que ce soit traduit par le compilateur en:
valeur := 1;
if not expression then
  valeur := autrechose;
 
J'ai déjà observé ce phénomène dans Delphi, pas moyen de mettre un breakpoint sur valeur := 1 suivant le if, car la ligne n'existait pas dans le programme compilé

Ma remarque est un peu hors-sujet mais avec un bon design objet (donc avec un langage orienté objet, en général), l'emploi de switch ou de if imbriqués devrait vraiment être exceptionnel. Il est bien plus propre, lisible, extensible, maintenable (...) de faire jouer le polymorphisme.
 
Maintenant c'est sur que des fois ça dépanne, et qu'on ne peut pas toujours se permettre de reprendre le design pour éviter un switch à deux cas.

 
design objet, design objet..
ca remplace juste le switch sur des types
pas sur des valeurs..

 
mais je dois etre de la vieille ecole..
 
LEGREG

 

C'est quoi le rapport ?

Le rapport entre mon post et le topic ou entre les switch et le polymorphisme ?

Bhen je vois pas trop en quoi l'orienté objet peut éviter dans quasi tout les cas les switch et les if imbriqué
Ok pas besoin de faire des
if objet is TMachin then
else if objet is TTruc then
else if objet is TBrol then
...
Mais y a quand même d'autres utilisations...

Ben disons qu'il faut prendre le problème dans l'autre sens. Il ne s'agit pas de créer son arborescence d'objets puis de constater a posteriori que certains switch portent sur le type d'objet alors que d'autres portent sur un de leur attribut ; il s'agit de créer son arborescence d'objets de façon à ce que ces switch portent autant que possible sur des types d'objets.
 
On est d'accord, c'est pas toujours possible (enfin surtout, c'est pas toujours intéressant). Mais d'expérience, en java, j'en ai pas fait souvent des switch.

moi je débute en prog

le CASE, c bcp mieux... sauf si tu n'as que 2 choix, mais sinon c le top quoi !
un IF/ELSE, c trop limité !

comment prendre un canon pour tuer une mouche...
 
chaque fois que tu as des switch/case dans une fonction tu dois declarer une hierachie de classe ? bonjour l'efficacite !

En C, le switch pour la maintenance de code et la lisibilité, le if pour les cas avancés.
 
Eu niveau compil, le switch et les ifs imbriqués donnent a peu près le même code, sauf quand le nombre de case est elevé, ou le switch est plus optimisé/optimisable

donc case ou équivalent...
 
c surement une remarque conne, mais je trouve ca hyper lisible, et simple à maintenir...tu classes les occurences dans l'ordre décroissant de proba pour la rapidité, et tu met les récups d'erreur à la fin... ca donne
 
Case le plus probable
...
Case le moins probable
Case erreur la plus probable
Case erreur la moins probable

complètement d'accord avec toi Jubijub, c klair que pour la maintenance, c vraiment le mieux, et de toute façon, à la compil, c comme des if imbriqués.. donc je vois pas pourquoi se priver de ça lors du codage, vu que c plus simple et plus compréhensible... en plus y'a moins de risque d'erreur de syntaxe..  
 
CASE poweeeeeeeeeer ;-)

En PERL, j'ai pris l'habitude de gérer mes switch par des hash, chaque clé représente un choix possible
 
Ca donne parfois un truc illisible mais l'expression apparaît sur une seule ligne

c quoi des hash ?
 
sous linux si tu met ca comme paramètre lors d'une décompression quelconque, ca te met des  ########### de progression....mais en prog ?