Vorteil der Umschaltung der if-else-Anweisung

Was ist die beste Vorgehensweise für die Verwendung einer switchAnweisung im Vergleich zur Verwendung einer ifAnweisung für 30 unsignedAufzählungen, bei denen etwa 10 eine erwartete Aktion haben (dies ist derzeit dieselbe Aktion) ? Leistung und Platz müssen berücksichtigt werden, sind jedoch nicht kritisch. Ich habe das Snippet abstrahiert, also hasse mich nicht für die Namenskonventionen.

switch Aussage:

// numError is an error enumeration type, with 0 being the non-error case
// fire_special_event() is a stub method for the shared processing

switch (numError)
{  
  case ERROR_01 :  // intentional fall-through
  case ERROR_07 :  // intentional fall-through
  case ERROR_0A :  // intentional fall-through
  case ERROR_10 :  // intentional fall-through
  case ERROR_15 :  // intentional fall-through
  case ERROR_16 :  // intentional fall-through
  case ERROR_20 :
  {
     fire_special_event();
  }
  break;

  default:
  {
    // error codes that require no additional action
  }
  break;       
}

if Aussage:

if ((ERROR_01 == numError)  ||
    (ERROR_07 == numError)  ||
    (ERROR_0A == numError)  || 
    (ERROR_10 == numError)  ||
    (ERROR_15 == numError)  ||
    (ERROR_16 == numError)  ||
    (ERROR_20 == numError))
{
  fire_special_event();
}

Schalter verwenden.

Im schlimmsten Fall generiert der Compiler denselben Code wie eine If-else-Kette, sodass Sie nichts verlieren. Wenn Sie Zweifel haben, geben Sie die häufigsten Fälle zuerst in die switch-Anweisung ein.

Im besten Fall findet der Optimierer möglicherweise einen besseren Weg, um den Code zu generieren. Ein Compiler erstellt häufig einen binären Entscheidungsbaum (speichert Vergleiche und Sprünge im Durchschnitt) oder erstellt einfach eine Sprungtabelle (funktioniert überhaupt ohne Vergleiche).

Für den Sonderfall, den Sie in Ihrem Beispiel angegeben haben, lautet der klarste Code wahrscheinlich:

if (RequiresSpecialEvent(numError))
    fire_special_event();

Dies verschiebt das Problem natürlich nur in einen anderen Bereich des Codes, aber jetzt haben Sie die Möglichkeit, diesen Test wiederzuverwenden. Sie haben auch mehr Möglichkeiten, wie Sie es lösen können. Sie könnten std :: set verwenden, zum Beispiel:

bool RequiresSpecialEvent(int numError)
{
    return specialSet.find(numError) != specialSet.end();
}

Ich schlage nicht vor, dass dies die beste Implementierung von RequiresSpecialEvent ist, nur dass es eine Option ist. Sie können weiterhin einen Schalter oder eine if-else-Kette oder eine Nachschlagetabelle oder eine Bitmanipulation für den Wert verwenden. Je dunkler Ihr Entscheidungsprozess wird, desto mehr Wert erhalten Sie, wenn Sie ihn in einer isolierten Funktion haben.

Der Wechsel ist schneller.

Versuchen Sie einfach, 30 verschiedene Werte in einer Schleife einzugeben, und vergleichen Sie sie mit dem gleichen Code mithilfe des Schalters, um festzustellen, wie viel schneller der Schalter ist.

Jetzt hat der Switch ein echtes Problem : Der Switch muss zur Kompilierungszeit die Werte in jedem Fall kennen. Dies bedeutet, dass der folgende Code:

// WON'T COMPILE
extern const int MY_VALUE ;

void doSomething(const int p_iValue)
{
    switch(p_iValue)
    {
       case MY_VALUE : /* do something */ ; break ;
       default : /* do something else */ ; break ;
    }
}

wird nicht kompiliert.

Die meisten Leute verwenden dann define (Aargh!), Und andere deklarieren und definieren konstante Variablen in derselben Kompilierungseinheit. Beispielsweise:

// WILL COMPILE
const int MY_VALUE = 25 ;

void doSomething(const int p_iValue)
{
    switch(p_iValue)
    {
       case MY_VALUE : /* do something */ ; break ;
       default : /* do something else */ ; break ;
    }
}

Am Ende muss der Entwickler also zwischen "Geschwindigkeit + Klarheit" und "Codekopplung" wählen.

(Nicht, dass ein Schalter nicht so geschrieben werden kann, dass er verdammt verwirrend ist ... Die meisten Schalter, die ich derzeit sehe, gehören zu dieser "verwirrenden" Kategorie "... Aber das ist eine andere Geschichte ...)

Bearbeiten 2008-09-21:

bk1e fügte den folgenden Kommentar hinzu: "Das Definieren von Konstanten als Aufzählungen in einer Header-Datei ist eine weitere Möglichkeit, dies zu handhaben."

Natürlich ist es das.

Der Zweck eines externen Typs bestand darin, den Wert von der Quelle zu entkoppeln. Das Definieren dieses Werts als Makro, als einfache const int-Deklaration oder sogar als Aufzählung hat den Nebeneffekt, dass der Wert eingefügt wird. Sollte sich also die Definition, der Aufzählungswert oder der konstante Wert ändern, wäre eine Neukompilierung erforderlich. Die externe Deklaration bedeutet, dass bei einer Wertänderung keine Neukompilierung erforderlich ist, die Verwendung von switch jedoch nicht möglich ist. Die Schlussfolgerung, Switch zu verwenden, erhöht die Kopplung zwischen dem Switch-Code und den als Fälle verwendeten Variablen . Wenn es in Ordnung ist, verwenden Sie den Schalter. Wenn es nicht ist, dann keine Überraschung.

.

Bearbeiten 2013-01-15:

Vlad Lazarenko kommentierte meine Antwort und gab einen Link zu seiner eingehenden Untersuchung des durch einen Schalter erzeugten Assembler-Codes. Sehr aufschlussreich: http://lazarenko.me/switch/

Der Compiler wird es trotzdem optimieren - wählen Sie den Schalter, da er am besten lesbar ist.

Der Switch, wenn auch nur zur besseren Lesbarkeit. Riesig, wenn Aussagen meiner Meinung nach schwerer zu pflegen und schwerer zu lesen sind.

FEHLER_01 : // absichtlicher

oder

(ERROR_01 == numError) ||

Letzteres ist fehleranfälliger und erfordert mehr Eingabe und Formatierung als das erste.

Code für die Lesbarkeit. Wenn Sie wissen möchten, was besser funktioniert, verwenden Sie einen Profiler, da Optimierungen und Compiler unterschiedlich sind und Leistungsprobleme selten dort auftreten, wo die Leute glauben, dass sie sind.

Verwenden Sie den Schalter, es ist das, wofür es ist und was Programmierer erwarten.

Ich würde jedoch die überflüssigen Falletiketten einfügen - nur damit sich die Leute wohl fühlen, habe ich versucht, mich daran zu erinnern, wann / welche Regeln für das Auslassen gelten.
Sie möchten nicht, dass der nächste Programmierer, der daran arbeitet, unnötig über Sprachdetails nachdenken muss (möglicherweise sind Sie es in ein paar Monaten!).

Compiler können wirklich gut optimieren switch. Aktuelle gcc ist auch gut in der Optimierung einer Reihe von Bedingungen in einemif .

Ich habe einige Testfälle auf Godbolt gemacht .

Wenn die caseWerte eng zusammen gruppiert sind, sind gcc, clang und icc intelligent genug, um mithilfe einer Bitmap zu überprüfen, ob ein Wert einer der besonderen ist.

zB gcc 5.2 -O3 kompiliert das switchto (und das ifetwas sehr ähnliches):

errhandler_switch(errtype):  # gcc 5.2 -O3
    cmpl    $32, %edi
    ja  .L5
    movabsq $4301325442, %rax   # highest set bit is bit 32 (the 33rd bit)
    btq %rdi, %rax
    jc  .L10
.L5:
    rep ret
.L10:
    jmp fire_special_event()

Beachten Sie, dass es sich bei der Bitmap um unmittelbare Daten handelt, sodass kein potenzieller Daten-Cache-Fehler beim Zugriff darauf oder eine Sprungtabelle auftritt.

gcc 4.9.2 -O3 kompiliert das switchzu einer Bitmap, macht das aber 1U<<errNumbermit mov / shift. Es kompiliert die ifVersion zu einer Reihe von Zweigen.

errhandler_switch(errtype):  # gcc 4.9.2 -O3
    leal    -1(%rdi), %ecx
    cmpl    $31, %ecx    # cmpl $32, %edi  wouldn't have to wait an extra cycle for lea's output.
              # However, register read ports are limited on pre-SnB Intel
    ja  .L5
    movl    $1, %eax
    salq    %cl, %rax   # with -march=haswell, it will use BMI's shlx to avoid moving the shift count into ecx
    testl   $2150662721, %eax
    jne .L10
.L5:
    rep ret
.L10:
    jmp fire_special_event()

Beachten Sie, wie 1 von subtrahiert wird errNumber(mit lea, um diese Operation mit einer Bewegung zu kombinieren). Dadurch kann die Bitmap sofort in eine 32-Bit-Version eingepasst werden, wobei die 64-Bit-Version sofort vermieden wirdmovabsq mehr Anweisungsbytes benötigt.

Eine kürzere (im Maschinencode) Sequenz wäre:

    cmpl    $32, %edi
    ja  .L5
    mov     $2150662721, %eax
    dec     %edi   # movabsq and btq is fewer instructions / fewer Intel uops, but this saves several bytes
    bt     %edi, %eax
    jc  fire_special_event
.L5:
    ret

(Die Nichtverwendung jc fire_special_eventist allgegenwärtig und ein Compiler-Fehler .)

rep retwird in Zweigzielen und folgenden bedingten Zweigen zum Nutzen des alten AMD K8 und K10 (Pre-Bulldozer) verwendet: Was bedeutet "rep ret"? . Ohne diese Funktion funktioniert die Verzweigungsvorhersage auf diesen veralteten CPUs nicht so gut.

bt(Bittest) mit einem Register arg ist schnell. Es kombiniert die Arbeit, eine 1 um errNumberBits nach links zu verschieben und a zu tuntest , hat aber immer noch eine Latenz von 1 Zyklus und nur einen einzigen Intel-UOP. Mit einem Speicherargument ist es aufgrund seiner viel zu CISC-Semantik langsam: Mit einem Speicheroperanden für die "Bitfolge" wird die Adresse des zu testenden Bytes basierend auf dem anderen Arg (geteilt durch 8) berechnet und isn Es ist nicht auf den 1-, 2-, 4- oder 8-Byte-Block beschränkt, auf den der Speicheroperand zeigt.

Aus den Befehlstabellen von Agner Fog geht hervor , dass ein Shift-Befehl mit variabler Anzahl langsamer ist als ein btneuerer Intel-Befehl (2 Uops anstelle von 1, und Shift erledigt nicht alles, was sonst noch benötigt wird).

Die Vorteile von switch () gegenüber anderen Fällen sind: - 1. Switch ist viel effizienter als if else, da jeder Fall nicht vom vorherigen Fall abhängt, im Gegensatz zu anderen Fällen, in denen einzelne Anweisungen auf wahre oder falsche Bedingungen überprüft werden müssen.

2. Wenn es eine Nr. Gibt. Bei den Werten für einen einzelnen Ausdruck ist die Groß- und Kleinschreibung flexibler, wenn dies der Fall ist, da in anderen Fällen die Beurteilung nur auf zwei Werten basiert, dh entweder wahr oder falsch.

3. Die Werte in switch sind benutzerdefiniert, während die Werte in if else case auf Einschränkungen basieren.

4. Im Fehlerfall können Anweisungen im Schalter leicht überprüft und korrigiert werden, was bei if else-Anweisungen vergleichsweise schwierig zu überprüfen ist.

5. Das Schaltergehäuse ist viel kompakter und leicht zu lesen und zu verstehen.

IMO ist dies ein perfektes Beispiel dafür, wofür Switch Fall-Through gemacht wurde.

Wenn Ihre Fälle in Zukunft wahrscheinlich gruppiert bleiben - wenn mehr als ein Fall einem Ergebnis entspricht - ist der Schalter möglicherweise leichter zu lesen und zu warten.

Sie funktionieren gleich gut. Die Leistung ist bei einem modernen Compiler ungefähr gleich.

Ich bevorzuge if-Anweisungen gegenüber case-Anweisungen, da sie lesbarer und flexibler sind. Sie können andere Bedingungen hinzufügen, die nicht auf numerischer Gleichheit basieren, z. B. "|| max <min". Aber für den einfachen Fall, den Sie hier gepostet haben, spielt es keine Rolle, tun Sie einfach das, was für Sie am besten lesbar ist.

Schalter ist definitiv bevorzugt. Es ist einfacher, sich die Liste der Fälle eines Switch anzusehen und sicher zu wissen, was er tut, als die lange if-Bedingung zu lesen.

Die Verdoppelung des ifZustands ist schwer für die Augen. Angenommen, einer der ==wurde geschrieben !=; würdest du es bemerken Oder wenn eine Instanz von 'numError' 'nmuError' geschrieben wurde, die gerade kompiliert wurde?

Ich würde im Allgemeinen lieber Polymorphismus anstelle des Schalters verwenden, aber ohne weitere Details des Kontexts ist es schwer zu sagen.

In Bezug auf die Leistung ist es am besten, einen Profiler zu verwenden, um die Leistung Ihrer Anwendung unter Bedingungen zu messen, die denen entsprechen, die Sie in freier Wildbahn erwarten. Andernfalls optimieren Sie wahrscheinlich am falschen Ort und auf die falsche Weise.

Ich bin mit der Kompatibilität der Switch-Lösung einverstanden, aber IMO entführen Sie den Switch hier.
Der Zweck des Schalters besteht darin, je nach Wert eine unterschiedliche Handhabung zu haben .
Wenn Sie Ihr Algo in Pseudocode erklären müssten, würden Sie ein if verwenden, weil es semantisch so ist: wenn Whatever_error dies tut ... Es
sei denn, Sie beabsichtigen, Ihren Code eines Tages so zu ändern, dass er für jeden Fehler einen bestimmten Code enthält Ich würde wenn verwenden .

Ich würde die if-Aussage aus Gründen der Klarheit und Konvention auswählen, obwohl ich sicher bin, dass einige anderer Meinung sind. Schließlich möchten Sie etwas tun, ifeine Bedingung ist wahr! Einen Schalter mit einer Aktion zu haben, scheint ein wenig ... unnötig.

Ich würde sagen, SWITCH verwenden. Auf diese Weise müssen Sie nur unterschiedliche Ergebnisse implementieren. Ihre zehn identischen Fälle können die Standardeinstellung verwenden. Sollte eine Änderung nur die Änderung explizit implementieren, müssen Sie die Standardeinstellung nicht bearbeiten. Es ist auch viel einfacher, Fälle zu einem SWITCH hinzuzufügen oder daraus zu entfernen, als IF und ELSEIF zu bearbeiten.

switch(numerror){
    ERROR_20 : { fire_special_event(); } break;
    default : { null; } break;
}

Vielleicht testen Sie sogar Ihren Zustand (in diesem Fall numerror) anhand einer Liste von Möglichkeiten, einem Array, damit Ihr SWITCH nicht einmal verwendet wird, es sei denn, es wird definitiv ein Ergebnis geben.

Da Sie nur 30 Fehlercodes haben, codieren Sie Ihre eigene Sprungtabelle und treffen dann alle Optimierungsentscheidungen selbst (der Sprung ist immer am schnellsten), anstatt zu hoffen, dass der Compiler das Richtige tut. Es macht auch den Code sehr klein (abgesehen von der statischen Deklaration der Sprungtabelle). Es hat auch den Nebeneffekt, dass Sie mit einem Debugger das Verhalten zur Laufzeit ändern können, wenn Sie dies benötigen, indem Sie die Tabellendaten direkt durchsuchen.

Ich bin mir bei Best Practices nicht sicher, aber ich würde den Schalter verwenden - und dann den absichtlichen Durchfall über "Standard" abfangen.

Ästhetisch tendiere ich dazu, diesen Ansatz zu bevorzugen.

unsigned int special_events[] = {
    ERROR_01,
    ERROR_07,
    ERROR_0A,
    ERROR_10,
    ERROR_15,
    ERROR_16,
    ERROR_20
 };
 int special_events_length = sizeof (special_events) / sizeof (unsigned int);

 void process_event(unsigned int numError) {
     for (int i = 0; i < special_events_length; i++) {
         if (numError == special_events[i]) {
             fire_special_event();
             break;
          }
     }
  }

Machen Sie die Daten etwas intelligenter, damit wir die Logik etwas dümmer machen können.

Mir ist klar, dass es komisch aussieht. Hier ist die Inspiration (wie ich es in Python machen würde):

special_events = [
    ERROR_01,
    ERROR_07,
    ERROR_0A,
    ERROR_10,
    ERROR_15,
    ERROR_16,
    ERROR_20,
    ]
def process_event(numError):
    if numError in special_events:
         fire_special_event()

while (true) != while (loop)

Wahrscheinlich wird die erste vom Compiler optimiert, was erklären würde, warum die zweite Schleife langsamer ist, wenn die Anzahl der Schleifen erhöht wird.

Beim Kompilieren des Programms weiß ich nicht, ob es einen Unterschied gibt. Aber was das Programm selbst betrifft und den Code so einfach wie möglich zu halten, denke ich persönlich, dass es davon abhängt, was Sie tun möchten. if else if else Aussagen haben ihre Vorteile, die ich denke:

Mit dieser Funktion können Sie eine Variable anhand bestimmter Bereiche testen. Sie können Funktionen (Standard Library oder Personal) als Bedingungen verwenden.

(Beispiel:

`int a;
 cout<<"enter value:\n";
 cin>>a;

 if( a > 0 && a < 5)
   {
     cout<<"a is between 0, 5\n";

   }else if(a > 5 && a < 10)

     cout<<"a is between 5,10\n";

   }else{

       "a is not an integer, or is not in range 0,10\n";

Wenn sonst, wenn sonst, können Aussagen (trotz Ihrer besten Versuche) in Eile kompliziert und chaotisch werden. Switch-Anweisungen sind in der Regel klarer, sauberer und leichter zu lesen. kann aber nur zum Testen gegen bestimmte Werte verwendet werden (Beispiel:

`int a;
 cout<<"enter value:\n";
 cin>>a;

 switch(a)
 {
    case 0:
    case 1:
    case 2: 
    case 3:
    case 4:
    case 5:
        cout<<"a is between 0,5 and equals: "<<a<<"\n";
        break;
    //other case statements
    default:
        cout<<"a is not between the range or is not a good value\n"
        break;

Ich bevorzuge if - else if - else-Aussagen, aber es liegt wirklich an Ihnen. Wenn Sie Funktionen als Bedingungen verwenden möchten oder etwas gegen einen Bereich, ein Array oder einen Vektor testen möchten und / oder es Ihnen nichts ausmacht, sich mit der komplizierten Verschachtelung zu befassen, würde ich die Verwendung von If else if else-Blöcken empfehlen. Wenn Sie anhand einzelner Werte testen möchten oder einen sauberen und leicht lesbaren Block wünschen, würde ich die Verwendung von case-Blöcken (switch ()) empfehlen.

Ich bin nicht die Person, die Ihnen etwas über Geschwindigkeit und Speichernutzung erzählt, aber das Betrachten einer Switch-Anweisung ist verdammt viel einfacher zu verstehen als eine große if-Anweisung (insbesondere 2-3 Monate später).

Ich weiß, dass es alt ist, aber

public class SwitchTest {
static final int max = 100000;

public static void main(String[] args) {

int counter1 = 0;
long start1 = 0l;
long total1 = 0l;

int counter2 = 0;
long start2 = 0l;
long total2 = 0l;
boolean loop = true;

start1 = System.currentTimeMillis();
while (true) {
  if (counter1 == max) {
    break;
  } else {
    counter1++;
  }
}
total1 = System.currentTimeMillis() - start1;

start2 = System.currentTimeMillis();
while (loop) {
  switch (counter2) {
    case max:
      loop = false;
      break;
    default:
      counter2++;
  }
}
total2 = System.currentTimeMillis() - start2;

System.out.println("While if/else: " + total1 + "ms");
System.out.println("Switch: " + total2 + "ms");
System.out.println("Max Loops: " + max);

System.exit(0);
}
}

Das Variieren der Schleifenzahl ändert sich stark:

Während if / else: 5ms Switch: 1ms Max Loops: 100000

Während if / else: 5ms Switch: 3ms Max Loops: 1000000

Während if / else: 5ms Switch: 14ms Max Loops: 10000000

Während if / else: 5ms Switch: 149ms Max Loops: 100000000

(Fügen Sie weitere Anweisungen hinzu, wenn Sie möchten)