Pourquoi devons-nous utiliser l'interrupteur de rodage?

Qui a décidé (et sur quels concepts) que la switchconstruction (dans de nombreuses langues) doit utiliser breakdans chaque énoncé?

Pourquoi devons-nous écrire quelque chose comme ceci:

switch(a)
{
    case 1:
        result = 'one';
        break;
    case 2:
        result = 'two';
        break;
    default:
        result = 'not determined';
        break;
}

(remarqué cela en PHP et JS; il y a probablement beaucoup d'autres langages qui l'utilisent)

Si switchest une alternative de if, pourquoi nous ne pouvons pas utiliser la même construction que pour if? C'est à dire:

switch(a)
{
    case 1:
    {
        result = 'one';
    }
    case 2:
    {
        result = 'two';
    }
    default:
    {
        result = 'not determined';
    }
}

On dit que cela breakempêche l'exécution du bloc suivant celui en cours. Mais, est-ce que quelqu'un se heurte réellement à la situation, où il était nécessaire d'exécuter le bloc actuel et les suivants? Je n'ai pas Pour moi, breakc'est toujours là. Dans chaque bloc. Dans chaque code.

C a été l’une des premières langues à avoir l’ switchénoncé sous cette forme, et toutes les autres langues principales en ont hérité, choisissant pour la plupart de conserver la sémantique C par défaut. les moins importants que de garder le comportement auquel tout le monde était habitué.

Quant à la raison pour laquelle C a été conçu de cette manière, il découle probablement du concept de C en tant qu '"assemblage portable". L' switchinstruction est fondamentalement une abstraction d'une table de branche , et une table de branche a également un impact implicite et nécessite une instruction de saut supplémentaire pour l'éviter.

Donc, fondamentalement, les concepteurs de C ont également choisi de conserver la sémantique de l’assembleur par défaut.

Parce que switchn'est pas une alternative de if ... elsedéclarations dans ces langues.

En utilisant switch, nous pouvons associer plus d'une condition à la fois, ce qui est très apprécié dans certains cas.

Exemple:

public Season SeasonFromMonth(Month month)
{
    Season season;
    switch (month)
    {
        case Month.December:
        case Month.January:
        case Month.February:
            season = Season.Winter;
            break;

        case Month.March:
        case Month.April:
        case Month.May:
            season = Season.Spring;
            break;

        case Month.June:
        case Month.July:
        case Month.August:
            season = Season.Summer;
            break;

        default:
            season = Season.Autumn;
            break;
    }

    return season;
}

Cela a été demandé pour Stack Overflow dans le contexte de C: Pourquoi l'instruction switch a-t-elle été conçue pour nécessiter une pause?

Pour résumer la réponse acceptée, c'était probablement une erreur. La plupart des autres langues ont probablement juste suivi C. Cependant, certaines langues telles que C # semblent avoir résolu ce problème en autorisant les retombées - mais uniquement lorsque le programmeur le dit explicitement (source: le lien ci-dessus, je ne parle pas C # moi-même) .

Je vais répondre avec un exemple. Si vous voulez lister le nombre de jours pour chaque mois de l’année, il est évident que certains mois en ont 31, 30 et 28/29. Cela ressemblerait à ceci,

switch(month) {
    case 4:
    case 6:
    case 9:
    case 11;
        days = 30;
        break;
    case 2:
        //Find out if is leap year( divisible by 4 and all that other stuff)
        days = 28 or 29;
        break;
    default:
        days = 31;
}

Ceci est un exemple où plusieurs observations ont le même effet et sont toutes regroupées. Il y avait évidemment une raison pour le choix du mot clé break et non pas le if ... sinon si construit.

La principale chose à prendre en compte ici est qu'une instruction switch avec beaucoup de cas similaires n'est pas un if ... sinon si ... sinon si ... sinon pour chacun des cas, mais plutôt si (1, 2, 3) ... sinon si (4,5,6) sinon ...

Il y a deux situations où «passer à travers» d'un cas à l'autre peut arriver - le cas vide:

switch ( ... )
{
  case 1:
  case 2:
    do_something_for_1_and_2();
    break;
  ...
}

et le cas non vide

switch ( ... )
{
  case 1:
    do_something_for_1();
    /* Deliberately fall through */
  case 2:
    do_something_for_1_and_2();
    break;
...
}

Nonobstant la référence au périphérique de Duff , les instances légitimes pour le second cas sont rares et généralement interdites par les normes de codage et signalées lors d'une analyse statique. Et là où il se trouve, il est le plus souvent dû à l’omission de a break.

Le premier est parfaitement sensé et commun.

Pour être honnête, je ne vois aucune raison d’avoir besoin de l’ breakanalyseur de langage et de l’analyseur de langage sachant qu’un corps de cas vide est un échec, alors qu’un cas non vide est autonome.

Il est dommage que le panel ISO C semble plus préoccupé par l'ajout de nouvelles fonctionnalités (non désirées) mal définies au langage, plutôt que par la correction des fonctionnalités non définies, non spécifiées ou définies par la mise en œuvre, sans parler de l'illogique.

Ne pas forcer le breakpermet un certain nombre de choses qui pourraient autrement être difficiles à faire. D'autres ont noté des cas de regroupement, pour lesquels il existe un certain nombre de cas non triviaux.

Un cas où il est impératif de breakne pas l'utiliser est le périphérique de Duff . Ceci est utilisé pour " dérouler " les boucles où il peut accélérer les opérations en limitant le nombre de comparaisons requises. Je pense que l’utilisation initiale permettait une fonctionnalité qui était auparavant trop lente avec une boucle entièrement enroulée. Il négocie la taille du code pour la vitesse dans certains cas.

Il est judicieux de remplacer le breakavec un commentaire approprié, si le cas contient du code. Sinon, quelqu'un corrigera les manquants breaket introduira un bogue.

En C, où l’origine semble être, le bloc de code de l’ switchinstruction n’est pas une construction spéciale. C'est un bloc de code normal, tout comme un bloc sous une ifinstruction.

switch ()
{
}

if ()
{
}

caseet defaultsont des étiquettes de saut à l'intérieur de ce bloc, spécifiquement liées à switch. Ils sont traités comme des étiquettes de saut normales goto. Il y a une règle spécifique qui est importante ici: les étiquettes de saut peuvent être presque partout dans le code, sans interrompre le flux de code.

En tant que bloc de code normal, il n'est pas nécessaire que ce soit une instruction composée. Les étiquettes sont également facultatives. Ce sont des switchdéclarations valables en C:

switch (a)
    case 1: Foo();

switch (a)
    Foo();

switch (a)
{
    Foo();
}

La norme C elle-même donne ceci à titre d'exemple (6.8.4.2):

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'identificateur est i existe avec une durée de stockage automatique (dans le bloc) mais n'est jamais initialisé. Ainsi, si l'expression de contrôle a une valeur différente de zéro, l'appel de la fonction printf accédera à une valeur indéterminée. De même, l'appel de la fonction f est inaccessible.

En outre, defaultest une étiquette de saut aussi, et peut donc être n'importe où, sans avoir à être le dernier cas.

Cela explique également le périphérique de Duff:

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

Pourquoi la chute? Parce que dans le flux de code normal dans un bloc de code normal, l'instruction suivante est attendue , tout comme vous le feriez dans un ifbloc de code.

if (a == b)
{
    Foo();
    /* "Fall-through" to Bar expected here. */
    Bar();
}

switch (a)
{
    case 1: 
        Foo();
        /* Automatic break would violate expected code execution semantics. */
    case 2:
        Bar();
}

Je suppose que la raison en était la facilité de mise en œuvre. Vous n'avez pas besoin de code spécial pour analyser et compiler un switchbloc, en prenant soin de règles spéciales. Vous venez de l'analyser comme n'importe quel autre code et vous ne devez vous soucier que des étiquettes et de la sélection de saut.

Une question intéressante de suivi de tout cela est si les déclarations imbriquées suivantes affichent "Terminé". ou pas.

int a = 10;

switch (a)
{
    switch (a)
    {
        case 10: printf("Done.\n");
    }
}

La norme C s'en occupe (6.8.4.2.4):

Un cas ou une étiquette par défaut est accessible uniquement dans l'instruction de commutateur englobante la plus proche.

Plusieurs personnes ont déjà évoqué la notion d'association de plusieurs conditions, ce qui est très précieux de temps en temps. Cependant, la possibilité de faire correspondre plusieurs conditions ne nécessite pas nécessairement que vous fassiez exactement la même chose pour chaque condition correspondante. Considérer ce qui suit:

switch (someCase)
{
    case 1:
    case 2:
        doSomething1And2();
        break;

    case 3:
        doSomething3();

    case 4:
        doSomething3And4();
        break;

    default:
        throw new Error("Invalid Case");
}

Il existe deux manières différentes de faire correspondre des ensembles de conditions multiples. Avec les conditions 1 et 2, ils tombent simplement dans la même parcelle de code et font exactement la même chose. Aux conditions 3 et 4, toutefois, bien que les deux appels aboutissent doSomething3And4(), seuls 3 appels sont nécessaires doSomething3().

Pour répondre à deux de vos questions.

Pourquoi C a-t-il besoin de pauses?

Cela revient aux racines de Cs en tant qu '"assembleur portable". Où psudo code comme celui-ci était commun: -

    targets=(addr1,addr2,addr3);
    opt = 1  ## or 0 or 2
switch:
    br targets[opt]  ## go to addr2 
addr1:
    do 1stuff
    br switchend
addr2:
    do 2stuff
    br switchend
addr3
    do 3stuff
switchend:
    ......

l'instruction switch a été conçue pour fournir des fonctionnalités similaires à un niveau supérieur.

Avons-nous des interrupteurs sans pause?

Oui, c'est assez courant et il y a quelques cas d'utilisation;

Premièrement, vous souhaiterez peut-être prendre la même mesure dans plusieurs cas. Nous faisons cela en empilant les cas les uns sur les autres:

case 6:
case 9:
    // six or nine code

Un autre cas d'utilisation courant dans les machines d'état est qu'après le traitement d'un état, nous souhaitons immédiatement entrer et traiter un autre état:

case 9:
    crashed()
    newstate=10;
case 10:
    claim_damage();
    break;

L'instruction Break est une instruction sautante qui permet à l'utilisateur de quitter le commutateur englobant le plus proche (pour votre cas), pendant que vous faites, pour ou pour chaque. c'est aussi simple que cela.

Je pense qu'avec tout ce qui est écrit ci-dessus - le principal résultat de ce fil est que si vous voulez concevoir un nouveau langage - la valeur par défaut devrait être que vous n'avez pas besoin d'ajouter une breakdéclaration et que le compilateur la traitera comme si vous l'aviez fait.

Si vous souhaitez que le cas rare où vous souhaitez passer à la prochaine affaire - indiquez-le simplement avec une continuedéclaration.

Cela peut être amélioré de manière à ce que cela ne se produise que si vous utilisez des accolades à l'intérieur du cas, de sorte que l'exemple avec les mois précédents de plusieurs cas exécutant le même code exact - fonctionne toujours comme prévu sans avoir besoin de continue.