die Frage der Zwischenwerte wird ebenfalls in deinem Link diskutiert. Es bleibt dabei:
switch/case basiert auf goto mit jump labels / jump tables und es entspricht NICHT if/ else if / else if.
Druckbare Version
die Frage der Zwischenwerte wird ebenfalls in deinem Link diskutiert. Es bleibt dabei:
switch/case basiert auf goto mit jump labels / jump tables und es entspricht NICHT if/ else if / else if.
Ursprünglich haben C-Compiler nur geschachtelte if/else erzeugt. Diese Variante funktioniert immer und der passende Code-Generator ist einfach.Zitat:
Zitat von Mxt
Ein grosser Nachteil ist das Laufzeitverhalten bei vielen Labels, um an das letzte Label zu gelangen müssen alle if abgearbeitet werden.
Allerdings haben diese dummen Compiler die Labels nicht sortiert, man konnte nachhelfen indem man die case entsprechend ihrer Wahrscheinlichkeit sortiert hat. Der Code war dann nicht unbedingt wirklich übersichtlicher.
Man darf nicht vergessen, dass in der Zeit als C entstand Hauptspeicher noch in Kilobyte und damalige Festplatten in Megabyte gemessen wurden.
Etwas später hat man dann angefangen die Labels zuerst zu analysieren.
Bei nur ein paar Label erzeugt man immer noch geschachtelte if/else, der Code-Overhead ist kleiner und die Laufzeitdifferenzen spielen auch keine Rolle.
Für Sprungtabellen ist es am einfachsten wenn die case-Werte feste Abstände haben. Bei nur einzelnen fehlenden Werten, werden diese einfach in der Tabelle eingeführt und zeigen auf das default-Label.
Bei einer zufälligen Verteilung der Werte bleibt dann nur noch die Möglichkeit eine Suchtabelle, welche wieder das selbe laufzeitverhalten wie verschachtelte if/else hat.
Bei der Frage nach dem Stack-Handling in C++ ist zu Bedenken, dass C++ ursprünglich als Pre-Prozessor konzipiert wurde. Im ersten Schritt wurde C++ einfach in ein C-Programm übersetzt und dann ging es mit dem normalen C-Compiler weiter.
Normalerweise kann man den C++-Compiler anweisen eine Datei mit diesem C-Code zu erstellen.
Dieser Schritt über C ist auch der Grund für die decorated names in C++. Es musste eine Lösung gefunden werden, damit C-Compiler und Linker mit identischen Funktions-Namen aber unterschiedlichen Parametern umgehen können. Also bastelt man sich aus den Parameter-Typen eine Codierung zusammen und bastelt diese an den Funktionsnamen dran. Für C und den Linker sind dies dann komplett unterschiedliche Funktionen.
MfG Peter(TOO)
Um endlich wieder bei
weiterzumachen:Zitat:
Frage: Wie kriegt der Stack diesen Ablauf gebacken ?
In C++ kommt noch eine weitere Komplexität hinzu. Das ist auch der Grund, warum gotos unerwartete Nebeneffekte haben können, die man nicht gut sieht, wenn über mehrere Bildschirmseiten gesprungen wird.
Nehmen wir mal an, man verwendet Dinge aus einer Arduino Lib, hier zur Demonstration mal mit Debug-Ausgaben
Wenn sowas jetzt in Code auftaucht, ein switch ist hier nur ein BeispielCode:struct Ding
{
~Ding()
{
Serial.printf("Fertig");
}
}
Dann ist die AusgabeCode:switch(i)
{
case 1:
{
Ding a;
// ....
break;
}
case 2:
/...
}
Serial.printf("Test");
Fertig
Test
Sowas kann auch passieren, wenn ein goto über { oder } hinwegspringt, vorwärts oder rückwärts.
- - - Aktualisiert - - -
Dazu reicht es einfach aus dem Link zu zitierenZitat:
Zitat von HaWe
Zitat:
...
Next, how do we jump to these calling targets?
...
The logic is not too hard to understand. ...Rewrite the snippet like this:
...
i2 = i;
if i2 > 700 goto LN14;
if i2 == 700 goto LN5;
if i2 > 250 goto LN15;
if i2 == 250 goto LN7;
if i2 == 100 goto LN9;
if i2 == 200 goto LN8;
goto LN1;
LN15:
if i2 == 500 goto LN6;
goto LN1;
LN14:
if i2 == 750 goto LN4;
if i2 == 800 goto LN3;
if i2 == 900 goto LN2;
goto LN1;
und siehe da...:
goto's, wer hätte das gedacht?
Und keine if /else if/else if/... sondern nur hintereinander geschriebene if's.
Natürlich kann man auch Fehler mit goto's machen, aber C ist ja gerade dafür entwickelt worden, um alles möglich zu machen - gehen tut alles mit C, der Programmierer ist für alles verantwortlich, auch für seine Fehler, und eben nicht die Programmiersprache oder der Compiler.
Whatever -
mein Standpunkt war ja nichts anderes als das gerade hier Beschriebene, goto's sind eben auch nicht viel anders als switch/case und keines ist schöner, besser oder vielseitiger oder mächtiger.
Für if /else if/else if/ gilt das allerdings schon, was das besser oder vielseitiger oder mächtiger anbelangt. Ich denke, auf diesen Standpunkt können wir uns ohne weiteres einigen.
Ja sicher.Zitat:
Zitat von HaWe
Und ja, in Assembler wird if else zu einer Art if goto, ein else gibt es da nicht.
Übrigens ist ein switch mittlerweile auch schon recht mächtig. Zwar noch nicht in der Arduino IDE, aber neuere C++ Compiler erlauben sowas
Gerade in Visual Studio getestet.Code:constexpr int quadrat(int n) noexcept
{
return n * n;
}
int main()
{
for (int i = 0; i < 10; i++)
{
switch (i)
{
case quadrat(1):
printf("i ist 1\r\n");
break;
case quadrat(2):
printf("i ist 4\r\n");
break;
case quadrat(3):
printf("i ist 9\r\n");
break;
default:
break;
}
}
return 0;
}
Wirklich sehr lehrreiche Diskussion und informative Ausführungen! Sorry, dass mein OT Deinem Assembler-Zusatz folgt. Aber sind nicht diese ganzenZitat:
.. Und ja, in Assembler wird if else zu einer Art if goto, ein else gibt es da nicht ..
Branch und Skip Befehle nicht genau für so ein "else" geeignet?Code:SBRC Rr, b Skip if Bit in Register Cleared if (Rr(b)=0) PC ← PC + 2 or 3 None 1/2/3
SBRS Rr, b Skip if Bit in Register is Set if (Rr(b)=1) PC ← PC + 2 or 3 None 1/2/3
...
BREQ k Branch if Equal if (Z = 1) then PC ← PC + k + 1 None 1/2
Anm: Auszug aus Atmel-42735A-ATmega328/P_Datasheet_Complete-06/2016, S432, 36. Instruction Set Summary.
Wahrscheinlich ja. Die Aussage "kein else" ist ja eventuell auch wieder Architekturabhäng. Manchal gibt es nur ein "jump if zero" und "jump if not zero", da muss ein if else dann natürlich etwas umgebaut werden.
"goto" wurde meiner Meinung nach nur in höhere Programmiersprachen aufgenommen um den Maschinensprachlern den Aufstieg zu erleichtern und wurde später nicht entfernt, um am Vorkommen im Sourcecode auf den erstn Blick den Anfängerauthor vom Fortgeschrittenen unterscheiden zu können ;-)
Manchmal gibt es nichts anderes (außer evtl. der Zerlegung in mehrere Funktionen)
und wie schon oben zitiert, viele Parsergeneratoren erzeugen Code mit vielen gotos.Code:for( ... ganzviel ...) {
for( ... nochmehr ...) {
for( ... immer mehr ...) {
if (bedingung) {
goto nix_wie_weg;
}
}
}
}
nix_wie_weg:
Zitat:
Zitat von Unregistriert
GOTO wurde nicht in Hochsprachen "aufgenommen".
In den ersten nicht Assembler Sprachen war GOTO und GOSUB die ersten und auch einzigen Verzweigungssmöglichkeiten in den Sprachen. Da wurde einfach eine eins zu eins Abbildung auf die verschiedenen JMP und BR Befehle vorgenommen.
Erst mit ALGOL wurde WHILE, FOR, IF, ELSE für Verzweigungen eingeführt.
GOTO funktioniert, denn beim Kompilieren werden alle modernen Konstrukte auf JMP und BR (bzw. ihren OPCode) zurückgeführt.
Die modernen Konstrukte halten einem halt die Arbeit vom Halse selbst den Überblick zu behalten und vor allem fördert es die Verständlichkeit und Lesbarkeit des Quellcodes.
Ich schreibe auch heute noch seitenlangen Code mit GOTO wenn es in der jeweiligen Sprache nichts anderes gibt. Allerdings bin ich es jetzt auch seit 34 Jahren so gewohnt.
Dafür sitzte ich aber auch vor Quellcode den ich vor X Jahren selbst geschrieben habe und brauche meine Zeit um zu verstehen was ich damals da gemacht habe und warum.
Ein Anfänger sollte sich halt überlegen ob er nicht gleich lernt zeitgemäß zu programmieren und sich zu verbessern oder Code zu produzieren der bei jeder Änderung fehleranfällig ist.
Der Arduino Compiler sollte schon mit GOTOs klar kommen. Aber optimieren wird er den Code wohl nicht großartig.
Es käme mal auf einen Versuch an die selbe Aufgabe einmal mit GOTOs und einmal ohne zu programmieren und dann zum einen festzustellen wie groß die beiden Compilate werden und welche Zykluszeiten sie dann bei der Ausführung haben.
1993 habe ich das mal für ein IBM S360 System mit Assembler, COBOL und APL2 gemacht. War interessant.