do{}while(false); -- ein besseres goto?
-
da behauptet ihr (hustbär und volkard) dann sicherlich auch, Lineare Optimierung funktioniert in der Praxis nicht, weil der Simplex in ungünstigen Fällen ja exponentiell läuft.
uiuiuiuiui ...
-
ps. der letzte Beitrag war ironisch gemeint. Habe leider die <irony on> ... <irony off>-Tags vergessen ...
-
u-ser_l schrieb:
da behauptet ihr (hustbär und volkard) dann sicherlich auch, Lineare Optimierung funktioniert in der Praxis nicht, weil der Simplex in ungünstigen Fällen ja exponentiell läuft.
uiuiuiuiui ...Kannst Du lesen? Dann tu es!
Tip: In meinen Postings stecken Aussagen über Relevanz.
-
Ich hab' jetzt den Thread hier so mitverfolgt und falle aus allen Wolken
. Im Kopf hatte ich goto als alle Struktur verseuchendes Teufelszeug prozeduraler Sprachen (hat mich allerdings bei ASM nie daran gehindert, mit netten jmp- Schweinereien herumzutricksen).
Eine zeitlang habe ich mit E-Lab- Pascal herumgetan, dessen goto so "grandios" implementiert war, daß man damit nicht mal einen begin end;- Block verlassen konnte, also völlig nutzlos war; deswegen habe ich mir das C- goto noch nicht einmal angesehen, das aber jetzt nachgeholt.Das ist ein absoluter Traum für die Fehlerbehandlung / Aufräumen!!
Wo ich vorher noch an allen returnpoints überlegen mußte, was noch alles gefreed/geclosed werden muß, geht jetzt alles an ein zentrales Label.
Ich hab' gerade sowas mit multiplen Fehlerpunkten in Arbeit, ist zwar eigentlich fertig, aber nachdem ich aus einer einzigen Funktion so fast 50 Zeilen schmeißen konnte, mach' ich mich nochmal über's ganze Projekt - übersichtlicher ist es auch geworden.Jetzt ist das goto so weit weg aus meinem Denken - wo macht es in C denn noch Sinn?
-
pointercrash() schrieb:
Jetzt ist das goto so weit weg aus meinem Denken - wo macht es in C denn noch Sinn?
Außer dem Aufräumblock mit mehrern Einsprunglabels, je nacdem, wieviel schon konstruiert wurde, hat es glaube ich gar keinen Lebensraum mehr.
Theoretisch vielleicht noch bei bestimmten endlichen Automaten, aber so einen habe ich in der Praxis noch nicht gesehen.
-
pointercrash() schrieb:
Ich hab' jetzt den Thread hier so mitverfolgt und falle aus allen Wolken
. Im Kopf hatte ich goto als alle Struktur verseuchendes Teufelszeug prozeduraler Sprachen (hat mich allerdings bei ASM nie daran gehindert, mit netten jmp- Schweinereien herumzutricksen).
Eine zeitlang habe ich mit E-Lab- Pascal herumgetan, dessen goto so "grandios" implementiert war, daß man damit nicht mal einen begin end;- Block verlassen konnte, also völlig nutzlos war; deswegen habe ich mir das C- goto noch nicht einmal angesehen, das aber jetzt nachgeholt.Das ist ein absoluter Traum für die Fehlerbehandlung / Aufräumen!!
Wo ich vorher noch an allen returnpoints überlegen mußte, was noch alles gefreed/geclosed werden muß, geht jetzt alles an ein zentrales Label.
Ich hab' gerade sowas mit multiplen Fehlerpunkten in Arbeit, ist zwar eigentlich fertig, aber nachdem ich aus einer einzigen Funktion so fast 50 Zeilen schmeißen konnte, mach' ich mich nochmal über's ganze Projekt - übersichtlicher ist es auch geworden.Jetzt ist das goto so weit weg aus meinem Denken - wo macht es in C denn noch Sinn?
Pauschal gibt es sonst nichts. Fast alle anderen Einsätze sind Fälle wo man mit Refactoring auch ohne auskommt (meist spart man dabei sogar Codezeilen und Kommentare ein, da dadurch der Code sprechender wird).
Du bist aber ein schönes Beispiel dafür was passiert, wenn man 40 Jahre alte Papers heute noch ohne Nachzudenken für aktuell befindet (dir gegenüber nicht negativ gemeint).
-
pointercrash() schrieb:
Jetzt ist das goto so weit weg aus meinem Denken - wo macht es in C denn noch Sinn?
immer dann, wenn die eingebauten kontrollstrukturen zu unflexibel sind, so dass du mit 'goto' was vereinfachen kannst. aber freu dich, dass du nicht in Java oder so programmieren darfst. da gibts nämlich absolute killer-gotos über methodengrenzen hinweg, die schimpfen sich 'exceptions' (naja, in C kannste sowas mit setjmp/longjmp erreichen).
volkard schrieb:
Theoretisch vielleicht noch bei bestimmten endlichen Automaten, aber so einen habe ich in der Praxis noch nicht gesehen.
ich auch nicht. state machines kenne ich nur mit verschachtelten switch/cases (meistens als output eines codegenerators, sowas von hand zu programmieren ist ziemlich übel), oder tabellengesteuert. und in oop-sprachen werden zustandsautomaten oft mit hilfe von vererbung gebastelt (class SomeState extends State, usw.).
ach ja, irgendwo gibt's noch'n beispiel von knuth, wie man sogenannte 'coroutines' mit gotos bauen kann.
-
u-ser_l schrieb:
hustbaer schrieb:
Diese ungünstigen Umstände hat man in einigen Fällen recht oft.
in einigen Fällen recht oft - was jetzt: "in einigen Fällen" oder "recht oft" ?
wie oft ist recht oft nach deiner subjektiven Meinung ?
Ich hoffe, wir wissen beide, daß der Fall vollkommen zufälliger branches in der Praxis selten vorkommt und deshalb moderne branch-predictions einen guten Job machen.
Also du willst unbedingt "weiter streiten". OK.
Was ich sagen wollte, und was für mich ausser Frage steht: es gibt einige Anwendungen, wo Branch-Prediction nicht gescheit funktioniert. Ein paar Beispiele hab' ich aufgezählt.
Das ist der "in einigen Fällen" Teil. Der "recht oft" Teil sollte heissen: dort haut Branch-Prediction recht oft daneben. War vielleicht etwas ungünstig formuliert.Anders gesagt: bei bestimmten Funktionen/Algorithmen, kann es auch mit der besten Branch-Prediction Sinn machen, die Algorithmen trotzdem auf "weniger Branches, mehr setcc/cmov" zu optimieren. Dass man z.B. einfache Pixel-Schleifen (Software-Rendering, 2D oder 3D) damit beschleunigen kann, weiss ich aus Erfahrung. (Auf einem Core 2 Duo, nicht auf irgendeiner Kindergarten CPU ohne brauchbare Branch-Prediction.)
Dass die Branch-Prediction im Allgemeinen sehr gut funktioniert, und dass das nichts ist worüber man sich in jedem Fall den Kopf zerbrechen sollte, ist für mich klar. Das wollte ich auch nicht in Abrede stellen.
Können wir uns darauf einigen?
-
ja
-
;fricky schrieb:
volkard schrieb:
Theoretisch vielleicht noch bei bestimmten endlichen Automaten, aber so einen habe ich in der Praxis noch nicht gesehen.
ich auch nicht. state machines kenne ich nur mit verschachtelten switch/cases (meistens als output eines codegenerators, sowas von hand zu programmieren ist ziemlich übel), oder tabellengesteuert. und in oop-sprachen werden zustandsautomaten oft mit hilfe von vererbung gebastelt (class SomeState extends State, usw.).
Ne, StateMachines bastel' ich anders, weil die Generatoren so häßliche switch-case Kaskaden abliefern. Ich vermute, daß das woanders auch schonmal gemacht wurde, aber ich hab's mal für mich so schematisiert:
Jeder Zustand ist eine Funktion, bedient sich aus Input, generiert Output und Folgezustand und liefert den als Funktionspointer zurück. Die aufrufende Routine (meist Timer- Interrupt) dereferenziert den Pointer und kriegt den Folgepointer zurück.
Damit kriegt man auch händisch Automaten hin, die lesbar bleiben und gutes Laufzeitverhalten haben.
-
pointercrash() schrieb:
Ich hab' jetzt den Thread hier so mitverfolgt und falle aus allen Wolken
.goto auf feste Sprungmarken ist doch langweilig. Stell Dir vor, der gcc Compiler unterstützt Zeiger auf Sprungmarken. Man kann einen Zeiger deklarieren, diesen zur Laufzeit setzen, und irgendwo im Code einfach goto Zeiger machen.
-
abc.w schrieb:
pointercrash() schrieb:
Ich hab' jetzt den Thread hier so mitverfolgt und falle aus allen Wolken
.goto auf feste Sprungmarken ist doch langweilig. Stell Dir vor, der gcc Compiler unterstützt Zeiger auf Sprungmarken. Man kann einen Zeiger deklarieren, diesen zur Laufzeit setzen, und irgendwo im Code einfach goto Zeiger machen.
nicht ganz, was du meinst, aber schon mächtiger als goto: man: sigsetjmp(3)
-
supertux schrieb:
nicht ganz, was du meinst, aber schon mächtiger als goto: man: sigsetjmp(3)
nein, ich meine das hier http://gcc.gnu.org/onlinedocs/gcc-4.4.1/gcc/Labels-as-Values.html#Labels-as-Values
-
supertux schrieb:
abc.w schrieb:
pointercrash() schrieb:
Ich hab' jetzt den Thread hier so mitverfolgt und falle aus allen Wolken
.goto auf feste Sprungmarken ist doch langweilig. Stell Dir vor, der gcc Compiler unterstützt Zeiger auf Sprungmarken. Man kann einen Zeiger deklarieren, diesen zur Laufzeit setzen, und irgendwo im Code einfach goto Zeiger machen.
nicht ganz, was du meinst, aber schon mächtiger als goto: man: sigsetjmp(3)
Nee, er meint schon goto auf Zeiger. Kleine gcc-Erweiterung, damit man in C++ nicht langsamer als in assembler ist.
-
abc.w schrieb:
goto auf feste Sprungmarken ist doch langweilig. Stell Dir vor, der gcc Compiler unterstützt Zeiger auf Sprungmarken. Man kann einen Zeiger deklarieren, diesen zur Laufzeit setzen, und irgendwo im Code einfach goto Zeiger machen.
naja, dafür hat man ja function pointer. nichts gegen 'goto', aber man kanns auch übertreiben.
pointercrash() schrieb:
...Jeder Zustand ist eine Funktion, bedient sich aus Input, generiert Output und Folgezustand und liefert den als Funktionspointer zurück. Die aufrufende Routine (meist Timer- Interrupt) dereferenziert den Pointer und kriegt den Folgepointer zurück.
das nennt sich dann, glaub ich, eine 'mealy machine'. aber klar, man kann sich die wildesten konstruktionen bauen, hauptsache das fest definierte verhalten wird garantiert, was ja die stärke solcher maschinen ist und was ziemlich komplexe abläufe 100% stabil und leicht handhabbar macht.
-
;fricky schrieb:
naja, dafür hat man ja function pointer. nichts gegen 'goto', aber man kanns auch übertreiben.
Dieses feature ist ziemlich wichtig für Emulatoren, die nicht für jeden emulierten Befehl den overhead eines Funktionsaufrufs haben wollen. Die bauen nämlich sowas dann ganz gerne in Assembler nach.
-
otze schrieb:
;fricky schrieb:
naja, dafür hat man ja function pointer. nichts gegen 'goto', aber man kanns auch übertreiben.
Dieses feature ist ziemlich wichtig für Emulatoren, die nicht für jeden emulierten Befehl den overhead eines Funktionsaufrufs haben wollen.
ok, aber switch/case sollte es auch tun. eine switch-anweisung könnte man ja auch als 'berechnetes goto' bezeichnen.
-
;fricky schrieb:
switch/case sollte es auch tun. eine switch-anweisung könnte man ja auch als 'berechnetes goto' bezeichnen.
Naja, goto auf Zeiger ist schon ne Klasse besser.
-
;fricky schrieb:
das nennt sich dann, glaub ich, eine 'mealy machine'. aber klar, man kann sich die wildesten konstruktionen bauen, hauptsache das fest definierte verhalten wird garantiert, was ja die stärke solcher maschinen ist und was ziemlich komplexe abläufe 100% stabil und leicht handhabbar macht.
Klar ist das ein Mealy- Automat, aber um sicherzustellen, daß keine parasitären Zyklen entstehen, mußtest Du das Ding bei allen Codegeneratoren (hab' vor etwa 3 Jahren die Opensource- Projekte zu dem Thema durchforstet) komplett ausdefinieren, als Ergebnis liefern die Dinger eine voll fette switch/case- Orgie ab, die man weder gut lesen kann noch performant ist, weil sie viel Irrelevantes mitprüft.
So 'ne schöne "don't care- Eliminierung" wie sie ABEL oder VHDL immanent bieten, hatten die bestenfalls auf der "todo- Liste".
Auf drei Vorteile wollte ich beim "Handschnitzen" hinaus:- Dont't Cares erzeugen keine Source, nichtexistente Source kann keine parasitären Zyklen bilden.
- Das Programm bleibt mit Deinen Bezeichnern und Deiner Logik voll debugbar. Wenn Du mal was übersehen hast und Dein Automat "hängt", siehst Du das eigentlich sofort.
- Wenn Du statt Tokens für Zustände gleich den Pointer auf den Folgezustand zurückgibst, sparst Du eine switch/case- Stufe in Source und Laufzeit.Ideal für Ablaufsteuerungen kann man aber auch andere Dinge in einen Mealy- Automaten pressen: Menüsysteme, Busprotokolle usw.
Und weil immer nur kleine Softwarehäppchen abgearbeitet werden, ergibt sich vor allem bei schwächeren µCs ein ausgeglichenes Laufzeitverhalten, weil's auf ein "Multitasking für Arme" hinausläuft.
