Ich meine das hier:

Event e = getEvent();
switch(e){
case MouseEvent:
break;
case KeyboardEvent:
break;
default:
break;
}

ist doch genau das gleiche wie das:

Event e = getEvent();
if(e == MouseEvent){}
else if(e == KeyboardEvent){}
else{}

demnach sind switch anweisungen doch eigentlich überflüssig oder nicht?
Gehe mal nicht davon aus, dass die wirklich unnötig sind, aber ich sehe von meinem blickwinkel keinen unterschied.

und besser zu lesen ist es auch mit if-anweisungen anstatt dem case: default: break; zeug

und besser zu lesen ist es auch mit if-anweisungen anstatt dem case: default: break; zeug

Auch nur wenn man so wie du formatiert.

switch ist eine Fallunterscheidung für Integer-Konstanten und kann übersichtlicher und um einiges schneller sein als eine entsprechende if - else -Kaskade.

ist doch genau das gleiche

Ohne die break nicht mehr...

demnach sind switch anweisungen doch eigentlich überflüssig oder nicht?

Demnach sind For -Schleifen doch eigentlich überflüssig oder nicht?

switch ist eine Fallunterscheidung für Integer-Konstanten und kann übersichtlicher und um einiges schneller sein als eine entsprechende if-else-Kaskade.

okay, also bei integer-konstanten lieber switch benutzen

Nee, while.
Ich schreibe lieber for(; bar; ) als std::size_t i = 0; while (i < bar) {foo(); ++i;}

Das war doch offensichtlich nicht ernst gemeint.

@TE: Siehe Antwort von Nexus, der Thread kann geschlossen werden

switch-case kann man auch einfacher debuggen. Dann springt der Compiler gleich an die richtige Stelle, bei if-else musst du alle Überprüfungen durchsteppen.

okay, also compileroptimierungen und einfacher zu debuggen. also wenn möglich bevorzugen?!

Wer von euch nimmt denn öfter switch und wer if?

Wer von euch nimmt denn öfter switch und wer if?

Natürlich nimmt man viel öfter if. switch-case geht ja nur in bestimmten Situationen. Aber wenn du schon sowas wie ein enum oder was ähnliches hast, wo du mehrere Werte abfragen willst, dann bietet sich switch-case eher an.

switch-case kann man auch einfacher debuggen. Dann springt der Compiler gleich an die richtige Stelle, bei if-else musst du alle Überprüfungen durchsteppen.

Was nun aber wirklich kein Grund ist, weshalb switch existiert. C (und C++ schon gar nicht) wurde nicht designt um einfach zu Debuggen zu sein und um schöne Fehlermeldungen zu erhalten.

@gamer8o4: Es gibt so eine These, dass alle if/else durch Polymorphie ersetzt werden können. Ich habe bei mir nur etwa alle 100 Zeilen ein if (10k Zeilen Statistikgrundlage). Muss auch nicht zwingend Runtimepolymorphie sein, Templates tuns auch. switch habe ich eines bei getopt aber das wars dann auch schon.

@gamer8o4: Es gibt so eine These, dass alle if/else durch Polymorphie ersetzt werden können. Ich habe bei mir nur etwa alle 100 Zeilen ein if (10k Zeilen Statistikgrundlage). Muss auch nicht zwingend Runtimepolymorphie sein, Templates tuns auch. switch habe ich eines bei getopt aber das wars dann auch schon.

echt? nur alle 100 zeilen eins? ich glaub ich sollte meinen programmierstil überarbeiten, aber ich wüsste garnicht viele stellen wo ich auf die if anweisungen verzichten könnte das man das mit templates lösen kann ist bei mir doch eher die ausnahme

rofl, den Code will ich sehen.

Der Code ist ein voll funktionsfähiger Interpreter einer Programmiersprache.

@gamer8o4: Zeig mal ein paar deiner ifs, dann kann ich mal schauen (und ohne externes C-Zeugs wie dein getEvent(), da hat man wirklich keine Wahl).

echt? nur alle 100 zeilen eins? ich glaub ich sollte meinen programmierstil überarbeiten

Du solltest nicht sofort auf alles hören, was dir jemand sagt. Allerdings stimmt es schon, dass man viele if Abfragen tatsächlich umgehen und eleganter lösen kann, eben auch durch Polymorphie oder Templates. Aber bitte nicht alle und schon gar nicht aus Prinzip, sondern nur wenns Sinn macht.

Btw: Natürlich habe ich ein paar ifs. Eben alle 100 Zeilen. Was ich nicht habe, sind immer wieder ähnliche ifs, die sich wiederholen. Eine verlinkte Liste würde ich zum Beispiel auch mit einem if schreiben.

Ich habe bei mir nur etwa alle 100 Zeilen ein if

Hm, muss ein recht primitives Programm sein. Oder ein Programmierstil, der viele Zeilen benötigt. Ich komme bei meiner Matrix-Klasse auf etwa 8 if's in 100 Zeilen.

Warst du nicht ein Fan von Alexandrescu? Von dem wirst du eine Linked List ohne if-Abfragen finden.

Btw: Natürlich habe ich ein paar ifs. Eben alle 100 Zeilen. Was ich nicht habe, sind immer wieder ähnliche ifs, die sich wiederholen. Eine verlinkte Liste würde ich zum Beispiel auch mit einem if schreiben.

Einen Stack als einfach verlinkte Liste würde ich ohne if schreiben. (Und natürlich ohne if-Plagiate als Polymorphie, ?:-Operator oder Schleifen, die maximal einmal laufen.)

Einen Stack oder eine Queue als doppelt verkettete Liste würde ich ohne if schreiben.

Eine Queue als einfach verlinkte Liste,... müßte ich mal machen, aber die Zeichen stehen eigentlich nicht so stark nach if.

if kostet Laufzeit und macht den Code unwartbar, weil man mehrere Zweige beachten muss. if ist böse. Es ist zu meiden. Aber nicht um jeden Preis.

@gamer8o4: Es gibt so eine These, dass alle if/else durch Polymorphie ersetzt werden können.

Oh, ich dachte fast, ich wäre allein bei so extremen Thesen.

Diese hier habe ich afair ungefähr Neujahr 2002 ausgetestet. Ein Programm, das Homepages uploaden kann per ftp, dazu liegen lokal ein Ausgabeverzeichnis und ein Spiegelverzeichnis (das immer gleich wie das aus dem Server ist) und das Programm synchronisiert Ausgabe- und Spiegenverzeichnis und updatet dabei das Serververzeichnis.

Das alles noch multithreaded mit mehreren ftp-Verbindungen. Gar nicht so einfach, weil bei vorhandener Datei /foo ein put /foo/bar erst nach rm /foo mkdir foo geht und dazu das rm /foo erst nach rm /foo/bar geht. Und die rm und mkdir sollten voll verschränkt sein, auch mit allen anderen put. So, daß die Gesamt-Onlinezeit minimal ist. Für Wählverbindungen. Daß keine Verbindung erstellt wird, wenn keine Updates zu erfolgen haben, ist wohl klar, damit man es auch regelmäßig Scriptgesteuert nutzen kann. Und auch kein schlichtes Probieren-und-Verwerfen, sondern ich legte erst singlethreaded einen Plan als Netzwerk mit Vor- und Nachbedingungen an und arbeitet den dann multithreaded ab.

Und das alles ohne if! Außer da, wo es aus der API erzwungen ist, beim Parsen der WIN32_FIND_DATA-Struktur. Die wird aber dann sofort je nachdem, ob Datei oder Verzeichnis in die passend Klasse gestopft, damit ab dann die Polymorphie greift.

Dabei nicht geschummelt mit statt if(a)b ein while(a);{b;break;}.

Das hat zwar geklappt, und der Code war in seiner eigenen Weise sogar wunderwunderschön. Aber wartbar war er nicht mehr. Hübscher Test, der mich sehr gut einjustiert hat, wo if und wo Polymorphie angemessener ist.

Siehe hier auch den Thread über MI oder nicht MI. Da testet einer, um man fast immer vererben kann, statt Attribute zu nehmen, leider testet er nicht, sondern tut es einfach, sogar in Produktiv-Code. Aua, wird der auf die Schnauze fallen.

bagger schrieb:

Ich habe bei mir nur etwa alle 100 Zeilen ein if (10k Zeilen Statistikgrundlage). Muss auch nicht zwingend Runtimepolymorphie sein, Templates tuns auch.

Das erscheint mir ein Bißchen zu wenig zu sein.

bagger schrieb:

switch habe ich eines bei getopt aber das wars dann auch schon.

Jo, switch ist quasi ausgestorben.

Es gibt so eine These, dass alle if/else durch Polymorphie ersetzt werden können.

Wieder mal ein gutes Beispiel, dass Code erst gut wird, wenn er kompliziert ist.

Das hier geht nur mit einem if und nie mit einem switch:

int i;
int j;
cin >> i >> j;

switch (i)
case j:
    cout << "Gleich" << endl;
    break;

Weil zur Compiletime muss der Ausdruck am case konstant sein. Dadurch ist das für dem Compiler halt leichter zu optimieren (statische Sprungtabelle).
Aber es ist halt nicht zur Laufzeit dynamisch als, dass man 2 Userinput vergleichen kann.