Instruction Switch: la valeur par défaut doit-elle être le dernier cas?

Considérez la switchdéclaration suivante :

switch( value )
{
  case 1:
    return 1;
  default:
    value++;
    // fall-through
  case 2:
    return value * 2;
}

Ce code se compile, mais est-il valide (= comportement défini) pour C90 / C99? Je n'ai jamais vu de code où le cas par défaut n'est pas le dernier cas.

EDIT:
Comme l' écrivent Jon Cage et KillianDS : c'est un code vraiment laid et déroutant et j'en suis bien conscient. Je suis juste intéressé par la syntaxe générale (est-elle définie?) Et le résultat attendu.

La norme C99 n'est pas explicite à ce sujet, mais en prenant tous les faits ensemble, elle est parfaitement valable.

A caseet defaultlabel sont équivalents à un gotolabel. Voir 6.8.1 Déclarations étiquetées. Particulièrement intéressant est 6.8.1.4, qui active le dispositif de Duff déjà mentionné:

Toute instruction peut être précédée d'un préfixe qui déclare un identifiant comme nom d'étiquette. Les étiquettes en elles-mêmes ne modifient pas le flux de contrôle, qui se poursuit sans entrave à travers elles.

Edit : Le code dans un commutateur n'a rien de spécial; c'est un bloc de code normal comme dans une ifinstruction-, avec des étiquettes de saut supplémentaires. Cela explique le comportement fall-through et pourquoi breakest nécessaire.

6.8.4.2.7 donne même un exemple:

switch (expr) 
{ 
    int i = 4; 
    f(i); 
case 0: 
    i=17; 
    /*falls through into default code */ 
default: 
    printf("%d\n", i); 
} 

Dans le fragment de programme artificiel, l'objet dont l'identifiant est i existe avec une durée de stockage automatique (dans le bloc) mais n'est jamais initialisé, et donc si l'expression de contrôle a une valeur différente de zéro, l'appel à la fonction printf accédera à une valeur indéterminée. De même, l'appel à la fonction f ne peut pas être atteint.

Les constantes de cas doivent être uniques dans une instruction switch:

6.8.4.2.3 L'expression de chaque étiquette de cas doit être une expression de constante entière et aucune des deux expressions de constante de cas dans la même instruction de commutation ne doit avoir la même valeur après conversion. Il peut y avoir au plus une étiquette par défaut dans une instruction switch.

Tous les cas sont évalués, puis il passe à l'étiquette par défaut, si elle est donnée:

6.8.4.2.5 Les promotions d'entiers sont effectuées sur l'expression de contrôle. L'expression constante dans chaque étiquette de cas est convertie en type promu de l'expression de contrôle. Si une valeur convertie correspond à celle de l'expression de contrôle promue, le contrôle passe à l'instruction suivant le libellé de cas correspondant. Sinon, s'il existe une étiquette par défaut, le contrôle passe à l'instruction étiquetée. Si aucune expression de constante de cas convertie ne correspond et qu'il n'y a pas d'étiquette par défaut, aucune partie du corps du commutateur n'est exécutée.

Les instructions case et l'instruction par défaut peuvent se produire dans n'importe quel ordre dans l'instruction switch. La clause par défaut est une clause facultative qui correspond si aucune des constantes des instructions case ne peut être mise en correspondance.

Bon exemple :-

switch(5) {
  case 1:
    echo "1";
    break;
  case 2:
  default:
    echo "2, default";
    break;
  case 3;
    echo "3";
    break;
}


Outputs '2,default'

très utile si vous voulez que vos cas soient présentés dans un ordre logique dans le code (comme dans, sans dire cas 1, cas 3, cas 2 / par défaut) et que vos cas sont très longs donc vous ne voulez pas répéter le cas entier code en bas pour la valeur par défaut

C'est valable et très utile dans certains cas.

Considérez le code suivant:

switch(poll(fds, 1, 1000000)){
   default:
    // here goes the normal case : some events occured
   break;
   case 0:
    // here goes the timeout case
   break;
   case -1:
     // some error occurred, you have to check errno
}

Le fait est que le code ci-dessus est plus lisible et plus efficace qu'en cascade if. Vous pourriez mettre defaultà la fin, mais cela ne sert à rien car cela concentrera votre attention sur les cas d'erreur au lieu des cas normaux (ce qui est le defaultcas ici ).

En fait, ce n'est pas un si bon exemple, car pollvous savez combien d'événements peuvent se produire au maximum. Mon vrai point est qu'il existe des cas avec un ensemble défini de valeurs d'entrée où il y a des «exceptions» et des cas normaux. S'il vaut mieux placer des exceptions ou des cas normaux au premier plan, c'est une question de choix.

Dans le domaine du logiciel, je pense à un autre cas très courant: les récursions avec certaines valeurs terminales. Si vous pouvez l'exprimer à l'aide d'un commutateur, defaultsera la valeur habituelle qui contient l'appel récursif et les éléments distingués (cas individuels) les valeurs du terminal. Il n'est généralement pas nécessaire de se concentrer sur les valeurs terminales.

Une autre raison est que l'ordre des cas peut changer le comportement du code compilé, ce qui compte pour les performances. La plupart des compilateurs génèrent du code d'assemblage compilé dans le même ordre que le code apparaît dans le commutateur. Cela rend le premier cas très différent des autres: tous les cas sauf le premier impliqueront un saut et cela videra les pipelines du processeur. Vous pouvez le comprendre comme un prédicteur de branche exécutant par défaut le premier cas apparaissant dans le commutateur. Si un cas est beaucoup plus courant que les autres, vous avez de très bonnes raisons de le mettre comme premier cas.

La lecture des commentaires est la raison spécifique pour laquelle l'affiche originale a posé cette question après avoir lu la réorganisation de la boucle de branche du compilateur Intel sur l'optimisation du code.

Ensuite, cela deviendra un arbitrage entre la lisibilité du code et les performances du code. Il vaut probablement mieux mettre un commentaire pour expliquer au futur lecteur pourquoi un cas apparaît en premier.

oui, c'est valable, et dans certaines circonstances c'est même utile. Généralement, si vous n'en avez pas besoin, ne le faites pas.

Il n'y a pas d'ordre défini dans une instruction switch. Vous pouvez considérer les cas comme quelque chose comme une étiquette nommée, comme une gotoétiquette. Contrairement à ce que les gens semblent penser ici, dans le cas de la valeur 2, l'étiquette par défaut n'est pas sautée. Pour illustrer avec un exemple classique, voici le dispositif de Duff , qui est l'affiche des extrêmes de switch/caseC.

send(to, from, count)
register short *to, *from;
register count;
{
  register n=(count+7)/8;
  switch(count%8){
    case 0: do{ *to = *from++;
    case 7:     *to = *from++;
    case 6:     *to = *from++;
    case 5:     *to = *from++;
    case 4:     *to = *from++;
    case 3:     *to = *from++;
    case 2:     *to = *from++;
    case 1:     *to = *from++;
            }while(--n>0);
  }
}

Un scénario dans lequel je considérerais qu'il est approprié d'avoir un «défaut» situé ailleurs que la fin d'une instruction de cas est dans une machine à états où un état invalide devrait réinitialiser la machine et procéder comme s'il s'agissait de l'état initial. Par exemple:

commutateur (widget_state)
{
  par défaut: / * Fell off the rails - reset and continue * /
    widget_state = WIDGET_START;
    /* Tomber dans */
  case WIDGET_START:
    ...
    Pause;
  case WIDGET_WHATEVER:
    ...
    Pause;
}

une disposition alternative, si un état invalide ne doit pas réinitialiser la machine mais doit être facilement identifiable comme un état invalide:

commutateur (widget_state)
{
  case WIDGET_IDLE:
    widget_ready = 0;
    widget_hardware_off ();
    Pause;
  case WIDGET_START:
    ...
    Pause;
  case WIDGET_WHATEVER:
    ...
    Pause;
  défaut:
    widget_state = WIDGET_INVALID_STATE;
    /* Tomber dans */
  case WIDGET_INVALID_STATE:
    widget_ready = 0;
    widget_hardware_off ();
    ... faire tout ce qui est nécessaire pour établir une condition "sûre"
}

Le code ailleurs peut alors vérifier (widget_state == WIDGET_INVALID_STATE) et fournir tout comportement de rapport d'erreur ou de réinitialisation d'état qui semble approprié. Par exemple, le code à barres d'état peut afficher une icône d'erreur et l'option de menu "Démarrer le widget", qui est désactivée dans la plupart des états non inactifs, peut être activée pour WIDGET_INVALID_STATE ainsi que WIDGET_IDLE.

Ajout d'un autre exemple: cela peut être utile si "default" est un cas inattendu et que vous voulez enregistrer l'erreur mais aussi faire quelque chose de sensé. Exemple de certains de mes propres codes:

  switch (style)
  {
  default:
    MSPUB_DEBUG_MSG(("Couldn't match dash style, using solid line.\n"));
  case SOLID:
    return Dash(0, RECT_DOT);
  case DASH_SYS:
  {
    Dash ret(shapeLineWidth, dotStyle);
    ret.m_dots.push_back(Dot(1, 3 * shapeLineWidth));
    return ret;
  }
  // more cases follow
  }

Il y a des cas où vous convertissez ENUM en chaîne ou convertissez une chaîne en enum dans le cas où vous écrivez / lisez dans / à partir d'un fichier.

Vous devez parfois définir l'une des valeurs par défaut pour couvrir les erreurs commises en modifiant manuellement les fichiers.

switch(textureMode)
{
case ModeTiled:
default:
    // write to a file "tiled"
    break;

case ModeStretched:
    // write to a file "stretched"
    break;
}

La defaultcondition peut être n'importe où dans le commutateur qu'une clause case peut exister. Il n'est pas nécessaire que ce soit la dernière clause. J'ai vu du code qui met la valeur par défaut comme première clause. Le case 2:est exécuté normalement, même si la clause par défaut est au-dessus.

En guise de test, j'ai mis l'exemple de code dans une fonction, appelée test(int value){}et exécutée:

  printf("0=%d\n", test(0));
  printf("1=%d\n", test(1));
  printf("2=%d\n", test(2));
  printf("3=%d\n", test(3));
  printf("4=%d\n", test(4));

La sortie est:

0=2
1=1
2=4
3=8
4=10

C'est valable, mais plutôt méchant. Je dirais qu'il est généralement mauvais d'autoriser les retombées car cela peut conduire à un code spaghetti très désordonné.

Il est presque certainement préférable de diviser ces cas en plusieurs instructions de commutation ou des fonctions plus petites.

[modifier] @Tristopia: Votre exemple:

Example from UCS-2 to UTF-8 conversion 

r is the destination array, 
wc is the input wchar_t  

switch(utf8_length) 
{ 
    /* Note: code falls through cases! */ 
    case 3: r[2] = 0x80 | (wc & 0x3f); wc >>= 6; wc |= 0x800; 
    case 2: r[1] = 0x80 | (wc & 0x3f); wc >>= 6; wc |= 0x0c0; 
    case 1: r[0] = wc;
}

serait plus clair quant à son intention (je pense) s'il était écrit comme ceci:

if( utf8_length >= 1 )
{
    r[0] = wc;

    if( utf8_length >= 2 )
    {
        r[1] = 0x80 | (wc & 0x3f); wc >>= 6; wc |= 0x0c0; 

        if( utf8_length == 3 )
        {
            r[2] = 0x80 | (wc & 0x3f); wc >>= 6; wc |= 0x800; 
        }
    }
}   

[edit2] @Tristopia: Votre deuxième exemple est probablement l'exemple le plus clair d'une bonne utilisation pour le suivi:

for(i=0; s[i]; i++)
{
    switch(s[i])
    {
    case '"': 
    case '\'': 
    case '\\': 
        d[dlen++] = '\\'; 
        /* fall through */ 
    default: 
        d[dlen++] = s[i]; 
    } 
}

..mais personnellement, je diviserais la reconnaissance des commentaires en sa propre fonction:

bool isComment(char charInQuestion)
{   
    bool charIsComment = false;
    switch(charInQuestion)
    {
    case '"': 
    case '\'': 
    case '\\': 
        charIsComment = true; 
    default: 
        charIsComment = false; 
    } 
    return charIsComment;
}

for(i=0; s[i]; i++)
{
    if( isComment(s[i]) )
    {
        d[dlen++] = '\\'; 
    }
    d[dlen++] = s[i]; 
}