Instrução Switch: o padrão deve ser o último caso?

Considere a seguinte switchdeclaração:

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

Esse código é compilado, mas é válido (= comportamento definido) para C90 / C99? Nunca vi código em que o caso padrão não seja o último.

Edição:
Como Jon Cage e KillianDS escrevem: este é um código realmente feio e confuso e eu estou ciente disso. Estou interessado apenas na sintaxe geral (está definida?) E na saída esperada.

O padrão C99 não é explícito sobre isso, mas, considerando todos os fatos, é perfeitamente válido.

A casee defaultlabel são equivalentes a um gotorótulo. Consulte 6.8.1 Instruções rotuladas. Especialmente interessante é o 6.8.1.4, que permite o já mencionado dispositivo de Duff:

Qualquer declaração pode ser precedida por um prefixo que declara um identificador como um nome de rótulo. Os rótulos em si não alteram o fluxo de controle, que continua desimpedido através deles.

Edit : O código dentro de um switch não é nada de especial; é um bloco de código normal como em uma ifdeclaração, com rótulos de salto adicionais. Isso explica o comportamento direto e por que breaké necessário.

6.8.4.2.7 até dá um exemplo:

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.

As constantes de caso devem ser exclusivas em uma instrução switch:

6.8.4.2.3 A expressão de cada rótulo de caso deve ser uma expressão constante inteira e não duas das expressões constantes de caso na mesma instrução switch devem ter o mesmo valor após a conversão. Pode haver no máximo um rótulo padrão em uma instrução switch.

Todos os casos são avaliados e, em seguida, passam para o rótulo padrão, se fornecido:

6.8.4.2.5 As promoções de números inteiros são realizadas na expressão de controle. A expressão constante em cada rótulo de caso é convertida no tipo promovido da expressão de controle. Se um valor convertido corresponder ao da expressão de controle promovida, o controle saltará para a instrução após o rótulo da caixa correspondente. Caso contrário, se houver um rótulo padrão, o controle pula para a instrução rotulada. Se nenhuma expressão constante de maiúscula convertida corresponder e não houver rótulo padrão, nenhuma parte do corpo do comutador será executada.

As instruções de caso e a instrução padrão podem ocorrer em qualquer ordem na instrução switch. A cláusula padrão é uma cláusula opcional que corresponde se nenhuma das constantes nas instruções de caso puder ser correspondida.

Bom exemplo :-

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


Outputs '2,default'

muito útil se você deseja que seus casos sejam apresentados em uma ordem lógica no código (como em não dizer caso 1, caso 3, caso 2 / padrão) e seus casos são muito longos, portanto, você não deseja repetir o caso inteiro código na parte inferior para o padrão

É válido e muito útil em alguns casos.

Considere o seguinte código:

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
}

O ponto é que o código acima é mais legível e eficiente do que em cascata if. Você pode colocar defaultno final, mas é inútil, pois concentrará sua atenção em casos de erro em vez de casos normais (que é o defaultcaso aqui ).

Na verdade, não é um exemplo tão bom, pois pollvocê sabe quantos eventos podem ocorrer no máximo. Meu verdadeiro ponto é que não são casos com um conjunto definido de valores de entrada, onde há 'exceções' e casos normais. Se é melhor colocar exceções ou casos normais na frente, é uma questão de escolha.

No campo do software, penso em outro caso muito comum: recursões com alguns valores terminais. Se você pode expressá-lo usando um comutador, defaultserá o valor usual que contém chamada recursiva e elementos distintos (casos individuais) dos valores do terminal. Geralmente, não há necessidade de se concentrar nos valores dos terminais.

Outro motivo é que a ordem dos casos pode alterar o comportamento do código compilado, e isso é importante para as performances. A maioria dos compiladores gerará código de montagem compilado na mesma ordem em que o código aparece no comutador. Isso torna o primeiro caso muito diferente dos outros: todos os casos, exceto o primeiro, envolvem um salto e esvaziam os pipelines do processador. Você pode entendê-lo como preditor de ramificação por padrão para executar o primeiro caso que aparece no comutador. Se um caso é muito mais comum que os outros, você tem boas razões para colocá-lo como o primeiro caso.

A leitura dos comentários é a razão específica pela qual o pôster original fez essa pergunta depois de ler a reorganização do Branch Loop do compilador Intel sobre otimização de código.

Então se tornará uma arbitragem entre a legibilidade e o desempenho do código. Provavelmente é melhor colocar um comentário para explicar ao futuro leitor por que um caso aparece primeiro.

Sim, isso é válido e, em algumas circunstâncias, é útil. Geralmente, se você não precisar, não faça.

Não há ordem definida em uma instrução switch. Você pode considerar os casos como algo como um rótulo nomeado, como um gotorótulo. Ao contrário do que as pessoas parecem pensar aqui, no caso do valor 2 o rótulo padrão não é utilizado. Para ilustrar com um exemplo clássico, aqui está o dispositivo de Duff , que é o filho dos extremos 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);
  }
}

Um cenário em que eu consideraria apropriado ter um 'padrão' localizado em algum lugar que não seja o final de uma instrução de caso está em uma máquina de estado em que um estado inválido deve redefinir a máquina e continuar como se fosse o estado inicial. Por exemplo:

switch (widget_state)
{
  padrão: / * Caiu nos trilhos - redefina e continue * /
    widget_state = WIDGET_START;
    /* Cair em */
  caso WIDGET_START:
    ...
    pausa;
  caso WIDGET_WHATEVER:
    ...
    pausa;
}

um arranjo alternativo, se um estado inválido não deve reiniciar a máquina, mas deve ser facilmente identificável como um estado inválido:

switch (widget_state)
{
  caso WIDGET_IDLE:
    widget_ready = 0;
    widget_hardware_off ();
    pausa;
  caso WIDGET_START:
    ...
    pausa;
  caso WIDGET_WHATEVER:
    ...
    pausa;
  padrão:
    widget_state = WIDGET_INVALID_STATE;
    /* Cair em */
  caso WIDGET_INVALID_STATE:
    widget_ready = 0;
    widget_hardware_off ();
    ... faça o que for necessário para estabelecer uma condição "segura"
}

O código em outro local pode então procurar por (widget_state == WIDGET_INVALID_STATE) e fornecer qualquer comportamento de relatório de erros ou redefinição de estado que pareça apropriado. Por exemplo, o código da barra de status pode mostrar um ícone de erro e a opção de menu "Iniciar widget", que está desativada na maioria dos estados não ociosos, pode ser ativada para WIDGET_INVALID_STATE e WIDGET_IDLE.

Discutindo com outro exemplo: Isso pode ser útil se "padrão" for um caso inesperado e você desejar registrar o erro, mas também fazer algo sensato. Exemplo de alguns dos meus próprios códigos:

  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
  }

Há casos em que você está convertendo ENUM em uma string ou convertendo em enum no caso de estar gravando / lendo em / de um arquivo.

Às vezes, você precisa tornar um dos valores padrão para cobrir erros cometidos pela edição manual de arquivos.

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

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

A defaultcondição pode estar em qualquer lugar dentro do comutador em que uma cláusula de caso possa existir. Não é necessário que seja a última cláusula. Eu vi o código que coloca o padrão como a primeira cláusula. O case 2:é executado normalmente, mesmo que a cláusula padrão esteja acima dele.

Como teste, coloquei o código de exemplo em uma função, chamada test(int value){}e executada:

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

A saída é:

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

É válido, mas bastante desagradável. Eu sugeriria que geralmente é ruim permitir falhas, pois isso pode levar a um código de espaguete muito confuso.

É quase certamente melhor dividir esses casos em várias instruções de chave ou em funções menores.

[edit] @Tristopia: Seu exemplo:

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

seria mais claro quanto à sua intenção (eu acho) se fosse escrito assim:

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: Seu segundo exemplo é provavelmente o exemplo mais limpo de um bom uso para acompanhamento:

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

..mas pessoalmente eu dividiria o reconhecimento de comentários em sua própria função:

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