2010-03-02 13 views
12

Estoy teniendo dificultades para comprender por qué el compilador requiere el uso de declaración de interrupción. No es posible perderlo ya que ahora se permite la caída. Veo el motivo de la ruptura en C o C++, pero ¿es necesario aquí?¿Por qué el compilador de C# requiere la declaración de interrupción en la construcción del conmutador?

¿Por qué no se rompe un comportamiento incorporado después de que se ha terminado un caso? ¿No es solo una sintaxis sin semántica?

Disculpe, si es una pregunta estúpida.

EDITAR: El derrumbe está permitido solo cuando la caja está vacía. Cuando hay una declaración allí, no puede omitir la declaración de interrupción. Entonces, es un asunto diferente.

+3

Probablemente solo para mantener a los chicos/chicas contentos mientras migran a un nuevo idioma. Tomo tu punto sobre por qué hacerlo obligatorio ... –

+1

Creo que es porque inevitablemente va a ser leído por personas que no están tan familiarizadas con C# pero que están familiarizadas con la sintaxis de C/C++. Tener el descanso explícito ayuda a la lectura para todos, aunque no sirva para nada. Es efectivamente compatible con versiones anteriores. – Dolbz

+1

Respuesta de los miembros de la comunidad Pithy C++: "Porque el lenguaje lo requiere". –

Respuesta

10

El compilador no necesita tanto las declaraciones de interrupción, sino que las exige.

Esta fue una decisión de diseño, comparable con el uso de ref al llamar a un método con un parámetro de paso por referencia.

Mantiene el código semánticamente cerca de C y C++ a la vez que elimina los inconvenientes de una caída que siempre fue una "característica" debatible de los lenguajes C.

+0

Entonces, solo por aclaración y no tiene ningún rol real? – anthares

+3

@anthares: Se podría decir eso. El compilador podría insertar fácilmente la ruptura, el programador no tiene otra opción aquí. Pero la 'legibilidad' es un papel importante para los constructos del lenguaje. –

+0

Sí cumple una función. El interruptor se traduce a las declaraciones goto en IL y eso es para tener mayor velocidad. digamos que tienes 10-20 casos; Con if/else, tendría un promedio de 10 comparaciones para llegar al caso correcto donde, al igual que con el goto generado, es mucho más rápido. –

3

La sentencia break en C# fue una decisión de diseño de los creadores del lenguaje ... Básicamente, querían una sentencia break "inequívoca", una sentencia break que solo funcionaría en una dirección. En resumen, no querían una caída, y si solo hubieran evitado la caída sin incluir "break", habría roto la compatibilidad con C++.

+0

Bien, ¿por qué este comportamiento no está incorporado sin la necesidad de declaración explícita de interrupción al final de los casos? Pueden hacerlo implícitamente, ¿verdad? – anthares

+2

Querían ser * explícitos * sobre no caerse. La declaración 'break' requerida es una * declaración * de que el código no se eliminará. –

+0

@RobertHarvey: Porque se permite el fracaso si la declaración está vacía. –

0

Por lo general, este tipo de código es un error:

// Contrived calculator demostration 
decimal x = 5m; 
decimal y = 10m; 
decimal result = 0m; 
string blah = "Divide"; 

// .. other code omitted 

switch(blah) { 
    case "Divide": 
     result = x/y; 

    case "Multiply": 
     result = x * y; 

    case "Add": 
     result = x + y; 

    case "Subtract": 
     result = x - y; 

    default: 
     MessageBox.Show("Not a valid operation"); 

} 

Sin embargo, el compilador no puede asumir los saltos que faltan son un error. Por lo que sabe, realmente quería que los casos fracasaran.

Simplemente suponiendo que los descansos deben darse al final de cada caso, solo cambiaría un error por uno diferente.

Por lo tanto, en su lugar, los diseñadores de idiomas no permitieron la caída desde casos no vacíos y generan un error si los omite.

Si necesita código compartido entre casos no vacíos, póngalo en un método private (posiblemente static) y llámelo desde allí.

Una última nota: los casos vacíos que caen son todo lo que se espera que haga un caso vacío, por lo que está permitido.

+0

En realidad, la pregunta era por qué los diseñadores de idiomas arrojan un error, en lugar de simplemente dividir implícitamente su caso una vez que lo haya hecho. – anthares

+1

Pero "El compilador no puede suponer que los saltos faltantes son un error". solo porque está escrito de esta manera. Dado que no se permite la caída en los casos no vacíos, la pregunta es cómo el compilador arroja un error en lugar de asumir el único comportamiento permitido. – anthares

+0

el compilador no puede suponer que los saltos faltantes son un error. Por lo que sabe, realmente quería que los casos fracasaran. Simplemente asumiendo que los descansos deberían estar al final de cada caso, solo cambiaría un error por otro diferente. – Powerlord

2

fallthrough se permite si la expresión caso está vacía:

case Foo: // fallthrough allowed. 
case Bar: 
    Console.WriteLine ("Foo or Bar"); 
    break; // required 

que no está permitido es un error común en la misma liga que "no se puede asignar valores en si-condiciones" *


* puede. La regla es que solo se permiten valores booleanos en condiciones if y x=false con bool x;es un valor booleano.

Cuestiones relacionadas