Por que precisamos usar o interruptor de interrupção?

Quem decidiu (e com base em quais conceitos) que a switchconstrução (em várias línguas) deve usar breakem cada declaração?

Por que temos que escrever algo como isto:

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

(notei isso em PHP e JS; provavelmente existem muitas outras linguagens usando isso)

Se switché uma alternativa de if, por que não podemos usar a mesma construção que para if? Ou seja:

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

Diz-se que breakimpede a execução do bloco após o atual. Mas, alguém realmente se depara com a situação, onde havia necessidade de execução do bloco atual e dos seguintes? Eu não fiz. Para mim, breakestá sempre lá. Em cada bloco. Em todo código.

C foi um dos primeiros idiomas a ter a switchdeclaração nesse formato, e todos os outros idiomas principais a herdaram a partir daí, optando principalmente por manter a semântica C por padrão - eles não pensaram nas vantagens de alterá-la ou julgaram menos importante do que manter o comportamento com o qual todos estavam acostumados.

Quanto ao motivo pelo qual o C foi projetado dessa maneira, provavelmente deriva do conceito de C como "montagem portátil". A switchinstrução é basicamente uma abstração de uma tabela de ramificação , e uma tabela de ramificação também possui uma queda implícita e requer uma instrução de salto adicional para evitá-la.

Então, basicamente, os designers de C também escolheram manter a semântica do assembler por padrão.

Porque switchnão é uma alternativa de if ... elsedeclarações nesses idiomas.

Ao usar switch, podemos combinar mais de uma condição por vez, o que é muito apreciado em alguns casos.

Exemplo:

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

Isso foi perguntado no Stack Overflow no contexto de C: Por que a instrução switch foi projetada para precisar de uma interrupção?

Para resumir a resposta aceita, provavelmente foi um erro. A maioria das outras linguagens provavelmente apenas seguiu o C. No entanto, algumas linguagens como o C # parecem ter corrigido isso ao permitir falhas - mas somente quando o programador o explicita (fonte: link acima, eu não falo C #) .

Eu responderei com um exemplo. Se você deseja listar o número de dias para cada mês do ano, é óbvio que alguns meses têm 31, 30 e 1 28/29. Ficaria assim,

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

Este é um exemplo em que vários casos têm o mesmo efeito e são todos agrupados. Obviamente, havia uma razão para a escolha da palavra-chave break e não a construção if ... else if .

O principal a ser observado aqui é que uma declaração switch com muitos casos semelhantes não é um if ... else se ... else if ... else para cada um dos casos, mas sim se (1, 2, 3) ... senão se (4,5,6) senão ...

Há duas situações em que pode ocorrer a ocorrência de um caso para outro - o caso vazio:

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

e o caso não vazio

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

Não obstante a referência ao dispositivo de Duff , as instâncias legítimas para o segundo caso são poucas e distantes entre si, e geralmente proibidas pelos padrões de codificação e sinalizadas durante a análise estática. E onde é encontrado, é mais frequentemente do que não devido à omissão de a break.

O primeiro é perfeitamente sensato e comum.

Para ser sincero, não vejo razão para precisar do breakanalisador e do idioma, sabendo que um corpo de caso vazio é uma falha, enquanto um caso não vazio é autônomo.

É uma pena que o painel ISO C pareça mais preocupado em adicionar recursos novos (indesejados) e mal definidos ao idioma, em vez de corrigir os recursos indefinidos, não especificados ou definidos pela implementação, sem mencionar os ilógicos.

Não forçar o breakpermite uma série de coisas que poderiam ser difíceis de fazer. Outros observaram casos de agrupamento, para os quais existem vários casos não triviais.

Um caso em que é imperativo que o breaknão seja usado é o dispositivo de Duff . Isso é usado para " desenrolar " loops, onde pode acelerar as operações, limitando o número de comparações necessárias. Acredito que o uso inicial permitia funcionalidades que antes eram muito lentas com um loop totalmente enrolado. Ele troca o tamanho do código pela velocidade em alguns casos.

É uma boa prática substituir o breakcomentário por um apropriado, se o caso tiver algum código. Caso contrário, alguém irá corrigir os desaparecidos breake introduzir um erro.

Em C, onde a origem parece estar, o bloco de código da switchinstrução não é uma construção especial. É um bloco de código normal, assim como um bloco em uma ifinstrução.

switch ()
{
}

if ()
{
}

casee defaultsão etiquetas de salto dentro deste bloco, especificamente relacionadas a switch. Eles são tratados da mesma maneira que os rótulos de salto normais goto. Há uma regra específica importante aqui: os rótulos de salto podem estar em quase toda parte do código, sem interromper o fluxo do código.

Como um bloco de código normal, ele não precisa ser uma instrução composta. Os rótulos também são opcionais. Estas são switchinstruções válidas em C:

switch (a)
    case 1: Foo();

switch (a)
    Foo();

switch (a)
{
    Foo();
}

O próprio padrão C fornece isso como um exemplo (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); 
} 

No fragmento de programa artificial, o objeto cujo identificador é i existe com duração automática de armazenamento (dentro do bloco), mas nunca é inicializado; portanto, se a expressão de controle tiver um valor diferente de zero, a chamada para a função printf acessará um valor indeterminado. Da mesma forma, a chamada para a função f não pode ser alcançada.

Além disso, também defaulté um rótulo de salto e, portanto, pode estar em qualquer lugar, sem a necessidade de ser o último caso.

Isso também explica o dispositivo 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);
}

Por que a queda? Como no fluxo de código normal em um bloco de código normal, é esperado o fall-through para a próxima instrução , assim como você esperaria em um ifbloco de código.

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

Meu palpite é que o motivo disso foi a facilidade de implementação. Você não precisa de código especial para analisar e compilar um switchbloco, cuidando de regras especiais. Você apenas o analisa como qualquer outro código e precisa cuidar apenas dos rótulos e da seleção de salto.

Uma questão interessante de acompanhamento disso tudo é se as seguintes declarações aninhadas imprimirem "Concluído". ou não.

int a = 10;

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

O padrão C cuida disso (6.8.4.2.4):

Um rótulo de caixa ou padrão é acessível apenas na declaração da chave anexa mais próxima.

Várias pessoas já mencionaram a noção de combinar várias condições, o que é muito valioso de tempos em tempos. No entanto, a capacidade de corresponder a várias condições não requer necessariamente que você faça exatamente a mesma coisa com cada condição que corresponda. Considere o seguinte:

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

    case 3:
        doSomething3();

    case 4:
        doSomething3And4();
        break;

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

Existem duas maneiras diferentes pelas quais conjuntos de várias condições são correspondidos aqui. Nas condições 1 e 2, eles simplesmente caem no mesmo lote de código e fazem exatamente a mesma coisa. Com as condições 3 e 4, no entanto, embora ambas terminem chamando doSomething3And4(), apenas 3 chamam doSomething3().

Para responder a duas de suas perguntas.

Por que C precisa de pausas?

Tudo se resume às raízes do Cs como um "montador portátil". Onde o código psudo como este era comum: -

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

a instrução switch foi projetada para fornecer funcionalidade semelhante em um nível superior.

Nós sempre temos interruptores sem interrupções?

Sim, isso é bastante comum e existem alguns casos de uso;

Primeiramente, você pode querer executar a mesma ação em vários casos. Fazemos isso empilhando os casos uns sobre os outros:

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

Outro caso de uso comum em máquinas de estado é que, após o processamento de um estado, queremos entrar e processar imediatamente outro estado:

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

A declaração de interrupção é uma declaração de salto que permite ao usuário sair do comutador anexo mais próximo (para o seu caso), enquanto, do, para ou foreach. é tão fácil quanto isso.

Eu acho que, com tudo o que foi escrito acima - o principal resultado desse segmento é que, se você deseja criar um novo idioma - o padrão deve ser que você não precise adicionar uma breakdeclaração e o compilador a tratará como se você o fizesse.

Se você deseja aquele caso raro em que deseja continuar para o próximo caso - basta declarar com uma continuedeclaração.

Isso pode ser aprimorado para que somente se você usar colchetes dentro do gabinete, ele não continuará, para que o exemplo com os meses acima de vários casos executando o mesmo código exato - funcione sempre como esperado sem a necessidade de continue.