2010-03-02 18 views
12

Ho difficoltà a capire perché il compilatore richiede l'uso dell'istruzione break. Non è possibile non vederlo perché è ormai permesso l'autunno. Vedo il motivo per l'interruzione in C o C++, ma è necessario qui.Perché il compilatore C# richiede l'istruzione break nella costruzione degli switch?

Perché non è un comportamento predefinito interrompere dopo un caso? Non è solo una sintassi senza semantica?

Scusa, se è una domanda stupida.

MODIFICA: il fall down è consentito solo quando il caso è vuoto. Quando c'è una dichiarazione, non puoi omettere la frase break. Quindi, è una questione diversa.

+3

Probabilmente solo per mantenere felici i ragazzi/ragazze che migrano in una nuova lingua. Prendo il tuo punto di vista sul perché renderlo obbligatorio ... –

+1

Penso che sia perché verrà letto da persone che non hanno familiarità con C# ma hanno familiarità con la sintassi C/C++. Avere la rottura esplicativa aiuta la leggibilità per tutti anche se non serve a nulla. È effettivamente compatibile all'indietro. – Dolbz

+1

Risposta del membro della comunità Pithy C++: "Perché la lingua lo richiede." –

risposta

10

Il compilatore non richiede tanto "le dichiarazioni di interruzione", ma le richiede.

Questa è stata una decisione di progettazione, paragonabile a richiedere l'uso di ref quando si chiama un metodo con un parametro pass-by-reference.

Mantiene il codice semanticamente vicino a C e C++ eliminando le insidie ​​di fall-through che è sempre stata una "caratteristica" discutibile dei linguaggi C.

+0

Quindi, solo per chiarimenti e non ha alcun ruolo attuale? – anthares

+3

@anthares: Si potrebbe dire questo. L'interruzione potrebbe essere facilmente inserita dal compilatore, il programmatore non ha altra scelta qui. Ma la 'leggibilità' è un ruolo importante per i costrutti del linguaggio. –

+0

Serve un ruolo. L'interruttore è tradotto in istruzioni goto nell'IL e deve avere maggiore velocità. diciamo che hai 10-20 casi; Con if/else se dovessi avere una media di 10 confronti per arrivare al caso giusto dove, come con il goto generato, è molto più veloce. –

3

L'istruzione break in C# è stata una decisione di progettazione da parte dei creatori del linguaggio ... Essenzialmente volevano un break statement "non ambiguo", una frase break che avrebbe funzionato solo in un modo. In breve, non volevano fall-through, e se avessero appena prevenuto il fall-through senza includere "break", avrebbero rotto la compatibilità all'indietro con C++.

+0

OK, perché allora questo comportamento non è incorporato senza la necessità di un'istruzione esplicita di interruzione alla fine dei casi. Possono farlo implicitamente, giusto? – anthares

+2

Volevano essere * espliciti * per non cadere. L'istruzione 'break' richiesta è una * dichiarazione * che il codice non cadrà. –

+0

@RobertHarvey: Perché _is_ permessa se l'istruzione è vuota. –

0

Di solito questo tipo di codice è un bug:

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

} 

Tuttavia, il compilatore non può assumersi le pause mancanti sono un bug. Per quanto ne sa, hai davvero voluto che i casi venissero meno.

Semplicemente supponendo che le interruzioni dovrebbero essere alla fine di ogni caso, sarebbe sufficiente scambiare un bug per un altro bug.

Così, invece, i progettisti di linguaggi non consentono il passaggio da casi non vuoti e generano un errore se li ometti.

Se è necessario il codice condiviso tra i casi non vuoti, inserirlo in un metodo private (possibilmente static) e chiamarlo da lì.

Un'ultima nota: i casi vuoti che ricadono sono tutto ciò che ci si aspetta da un caso vuoto, motivo per cui è consentito.

+0

In realtà la domanda è stata la ragione per cui i progettisti di linguaggi hanno commesso un errore, invece di rompere implicitamente il caso dopo che è stato fatto. – anthares

+1

Ma "Il compilatore non può supporre che le interruzioni mancanti siano un bug." solo perché è scritto in questo modo. Dal momento che il fall-through in casi non vuoti non è consentito la domanda è il modo in cui il compilatore genera un errore, invece assume l'unico comportamento consentito. – anthares

+0

il compilatore non può supporre che le interruzioni mancanti siano un bug. Per quanto ne sa, hai davvero voluto che i casi venissero meno. Semplicemente supponendo che le interruzioni dovrebbero essere alla fine di ogni caso, scambieresti solo un bug per un altro bug. – Powerlord

2

falltrough è consentito se l'espressione caso è vuota:

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

Che non è consentito è un errore comune nella stessa lega come "non è possibile assegnare valori in se-condizioni" *


* È possibile. La regola è che solo i valori booleani sono consentiti in condizioni if, e x=false con bool x;è un valore booleano pari a.

Problemi correlati